From majordomo@mil.doit.wisc.edu  Mon Jun  2 01:15:24 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12153
	for <ipfix-archive@lists.ietf.org>; Mon, 2 Jun 2003 01:15:23 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19MhCC-0005GJ-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 01 Jun 2003 23:45:20 -0500
Received: from palrel13.hp.com ([156.153.255.238])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19MhCA-0005GC-00
	for ipfix@net.doit.wisc.edu; Sun, 01 Jun 2003 23:45:18 -0500
Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62])
	by palrel13.hp.com (Postfix) with ESMTP
	id 741AD1C00C29; Sun,  1 Jun 2003 21:44:43 -0700 (PDT)
Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63])
	by xparelay1.ptp.hp.com (Postfix) with ESMTP
	id E74421004B9C; Sun,  1 Jun 2003 21:44:42 -0700 (PDT)
Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <L59KXBNT>; Sun, 1 Jun 2003 21:44:42 -0700
Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50295FFF2@xsun01.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Juergen Quittek'" <quittek@ccrle.nec.de>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        Sebastian Zander <zander@fokus.fraunhofer.de>
Cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] IPFIX requirements - final changes
Date: Sun, 1 Jun 2003 21:44:41 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Juergen,

  "and/or" or "or" either way works for me.

-- Jeff

-----Original Message-----
From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
Sent: Friday, May 30, 2003 3:28 PM
To: MEYER,JEFFREY D (HP-Cupertino,ex1); Sebastian Zander
Cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] IPFIX requirements - final changes


Jeff,

-- MEYER,JEFFREY D (HP-Cupertino,ex1) wrote on 30 May 2003 11:43 -0700:

> Juergen,
>
>   Your phrasing sounds good:
>
>  "Many requirements in this document are not explicitly
>   stated as IPFIX protocol requirements, but as requirements
>   for the metering process, the exporting process, or for
>   other traffic measurement components. However, every
>   requirement that needs support from the IPFIX protocol
>   MUST be covered by the IPFIX protocol specification
>   independent of the significance of the requirement,
>   which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
>   Note that the protocol specification itself also assigns
>   significance attributes to its features, such that a
>   protocol implementation does not necessarily need to
>   implement all features."
>
>   One change I would suggest is to recognize that the specification
> contains both a protocol and an (extendable) information model.
> E.g. anonymization can be addressed w/o any change to the
> protocol.
>
>   So I'd rather see one of the sentences modified as:
>
>     However, every requirement that needs support from the
>   IPFIX protocol or information model MUST be covered by the
>   IPFIX protocol or information model specification
>   independent of the significance of the requirement

Agreed.
Maybe we should replace two times 'or' by 'and/or'.

    Juergen


> Regards,
>
>   Jeff Meyer
>
>> -----Original Message-----
>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>> Sent: Friday, May 30, 2003 5:50 AM
>> To: Sebastian Zander
>> Cc: ipfix@net.doit.wisc.edu
>> Subject: Re: [ipfix] IPFIX requirements - final changes
>>
>>
>> Sebastian,
>>
>> -- Sebastian Zander wrote on 29 May 2003 03:29 +0200:
>>
>> > Juergen,
>> >
>> > Juergen Quittek wrote:
>> >> Sebastian,
>> >>
>> >> -- Sebastian Zander wrote on 28 May 2003 12:18 +0200:
>> >>
>> >>> Hi Juergen,
>> >>>
>> >>> i think your second paragraph is a very good idea. But i don't
>> >>> understand the last 2 sentences. My understanding is that
>> the ipfix
>> >>> requirement draft defines the ipfix protocol
>> requirements. So i don't
>> >>> understand why the protocol specification must cover all
>> requirements.
>> >>> E.g. when a requirementis optional why must it be covered
>> in the protocol
>> >>> specification?
>> >>
>> >>
>> >> If the requirement doc says "the exporter MAY anonymize", then the
>> >> protocol specification MUST support anonymization in order to make
>> >> sure, that anonymization is interoperable. For example the protocol
>> >> spec MUST define how to inform a collecting process that
>> the data it
>> >> receives is anonymized. Analogously, the protocol spec
>> should specify
>> >> how to encrypt.
>> >>
>> >> In both cases, the protocol specification can state that a concrete
>> >> implementation of the protocol MAY support features that serve
>> >> anonymization. Then an implementor can choose whether or
>> not to implement
>> >> this OPTIONAL feature of the protocol.
>> >
>> > You are right. The req draft contains protocol
>> specification requirements
>> > (which is sometimes confusing and the reason why we get
>> those comments).
>> > But i suggest to change the middle sentence saying that all protocol
>> > specification requirements from the req draft must be taken
>> over into the
>> > protocol draft *including their significance*. Otherwise
>> why do we spend a
>> > long time discussing the significance of some reqs if it is
>> not used later
>> > in the protocol draft? Furthermore some of the reqs may be
>> targeting the
>> > information model or achitecture draft instead of the
>> protocol spec. So
>> > the sentence should not only mention the protocol spec but *also the
>> > information model etc*. (Jeff just gave an example that
>> anonymization may
>> > influence the information model.)
>>
>> I see your point, but I would suggest a different phrasing for the
>> following reason:
>>   - I do not expect that requirement items can be mapped
>> one-to-one onto
>>     protocol features. Some individual protocol feature will
>> cover several
>>     requirement items at once. So here you cannot map the significance
>>     one-to-one, but need something like a minimum significance to be
>>     considered.
>>   - My experience from designing other protocols is that -
>> compared to the
>>     requirements - you usually increase significance of some features
>>     for technical or orther reasons. We must make sure that
>> the protocol
>>     definition process has this level of freedom.
>>
>> Therefore, I suggest to extend my initially suggested paragraph
>>
>>  "Many requirements in this document are not explicitly
>>   stated as IPFIX protocol requirements, but as requirements
>>   for the metering process, the exporting process, or for
>>   other traffic measurement components. However, every
>>   requirement that needs support from the IPFIX protocol
>>   MUST be covered by the IPFIX protocol specification
>>   independent of the significance of the requirement,
>>   which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
>>   Note that the protocol specification itself also assigns
>>   significance attributes to its features, such that a
>>   protocol implementation does not necessarily need to
>>   implement all features."
>>
>> by appending this sentence or a similar one:
>>
>>  "However, the significance assigned to a protocol feature
>>   MUST NOT be lower than the significance of the corresponding
>>   requirements."
>>
>> Cheers,
>>
>>     Juergen
>>
>>
>> > This statement must be put in the very beginning of the req draft.
>> >
>> > The last sentence is not necessary in my opinion because
>> its pretty obvious
>> > that the protocol draft and the other drafts will use more (and more
>> > detailed) reqs.
>> >
>> > Then there is no need to change the requirements to MUST.
>> >
>> > Cheers,
>> >
>> > Sebastian
>> >
>> >>> I agree to say its a MUST for the protocol but not all exporters
>> >>> and collectors must support it.
>> >>
>> >>
>> >> Agreed.
>> >>
>> >>> But i do *not* agree at all that in general anonymization and
>> >>> confidentiality is not needed in a LAN. Anonymization can
>> be required
>> >>> in a LAN and even in a LAN confidentiality may be needed because i
>> >>> don't want everybody who has access to my LAN to have access to my
>> >>> IPFIX data.
>> >>
>> >>
>> >> Also agreed.
>> >>
>> >> Best wishes,
>> >>
>> >>    Juergen
>> >>
>> >>> Cheers,
>> >>>
>> >>> Sebastian
>> >>>
>> >>> Juergen Quittek wrote:
>> >>>
>> >>>> Tal, Reinaldo, and Benoit,
>> >>>>
>> >>>> Do we all have the following in mind?
>> >>>>
>> >>>>   Anonymization and confidentiality MUST be covered by the
>> >>>>   protocol specification.  But the protocol specifiction
>> >>>>   specification defines it as a MAY feature (anonymization)
>> >>>>   or SHOULD feature (confidentiality) for IPFIX protocol
>> >>>>   implementations.
>> >>>>
>> >>>> I guess this is what the IESG reviewers were referring to.
>> >>>>
>> >>>> What is probably missing in the requirements document is a
>> >>>> statement like the following:
>> >>>>
>> >>>>   Many requirements in this document are not explicitly
>> >>>>   stated as IPFIX protocol requirements, but as requirements
>> >>>>   for the metering process, the exporting process, or for
>> >>>>   other traffic measurement components. However, every
>> >>>>   requirement that needs support from the IPFIX protocol
>> >>>>   MUST be covered by the IPFIX protocol specification
>> >>>>   independent of the significance of the requirement,
>> >>>>   which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
>> >>>>   Note that the protocol specification itself also assigns
>> >>>>   significance attributes to its features, such that a
>> >>>>   protocol implementation does not necessarily need to
>> >>>>   implement all features.
>> >>>>
>> >>>> Any comment on this?
>> >>>>
>> >>>>    Juergen
>> >>>>
>> >>>>
>> >>>> -- Tal Givoly wrote on 26 May 2003 09:42 -0700:
>> >>>>
>> >>>>> Juergen,
>> >>>>>
>> >>>>> I agree with Benoit - it doesn't make sense to make
>> confidentiality and
>> >>>>> anonymization mandatory. In many deployments, there could be
>> >>>>> physical and
>> >>>>> other security measures that addresses these issues.
>> >>>>>
>> >>>>> Tal
>> >>>>>
>> >>>>> -----Original Message-----
>> >>>>> From: majordomo listserver
>> [mailto:majordomo@mil.doit.wisc.edu]On
>> >>>>> Behalf
>> >>>>> Of Benoit Claise
>> >>>>> Sent: Monday, May 26, 2003 8:02 AM
>> >>>>> To: Juergen Quittek
>> >>>>> Cc: ipfix@net.doit.wisc.edu
>> >>>>> Subject: Re: [ipfix] IPFIX requirements - final changes
>> >>>>>
>> >>>>>
>> >>>>> Juergen,
>> >>>>>
>> >>>>>>
>> ==============================================================
>> ==========
>> >>>>>>
>> >>>>>> 12. Confidentiality from SHOULD to MUST
>> >>>>>>
>> ==============================================================
>> ==========
>> >>>>>>
>> >>>>>> Problem Description:
>> >>>>>>
>> --------------------------------------------------------------
>> ----------
>> >>>>>>
>> >>>>>> Requirements on the ipfix implementation - the
>> document is long and I
>> >>>>>> wonder if
>> >>>>>> the working group really meant the protocol's
>> confidentiality and
>> >>>>>> anonymization
>> >>>>>> features to be so optional -  SHOULD confidentiality, MAY
>> >>>>>> anonymization.
>> >>>>>> Just for implementation.
>> >>>>>>
>> ==============================================================
>> ==========
>> >>>>>>
>> >>>>>> Suggested solution:
>> >>>>>>
>> --------------------------------------------------------------
>> ----------
>> >>>>>>
>> >>>>>>   change confidentiality requirement in section 6.3.3
>> >>>>>>   from SHOULD to MUST
>> >>>>>>
>> ==============================================================
>> ==========
>> >>>>>>
>> >>>>>> Status: solution to be agreed on
>> >>>>>>
>> ==============================================================
>> ==========
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> I'm just wondering if a MUST is not a little bit extreme.
>> >>>>> The draft would become:
>> >>>>>    "Confidentiality of flow specific data transferred
>> from an exporting
>> >>>>>    process to a collecting process MUST be ensured."
>> >>>>> We all agree that over the Internet confidentiality is
>> compulsory but
>> >>>>> this sentence would mean that even in a private LAN or
>> environment, we
>> >>>>> must have confidentiality to be IPFIX compliant. And we
>> know that, with
>> >>>>> the software based encryption, the throughput would be
>> lowered. Ok,
>> >>>>> then
>> >>>>> we should have an crypto engine in hardware on the
>> exporter to export
>> >>>>> the numerous flow export packets but there is a price to it.
>> >>>>> My point is that, as Confidentiality is not needed in
>> all cases, why
>> >>>>> make it a MUST?
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> ==============================================================
>> ==========
>> >>>>>>
>> >>>>>> 13. Anonymization from MAY to MUST
>> >>>>>>
>> ==============================================================
>> ==========
>> >>>>>>
>> >>>>>> Problem Description:
>> >>>>>>
>> --------------------------------------------------------------
>> ----------
>> >>>>>>
>> >>>>>> Requirements on the ipfix implementation - the
>> document is long and I
>> >>>>>> wonder if
>> >>>>>> the working group really meant the protocol's
>> confidentiality and
>> >>>>>> anonymization
>> >>>>>> features to be so optional -  SHOULD confidentiality, MAY
>> >>>>>> anonymization.
>> >>>>>> Just for implementation.
>> >>>>>>
>> ==============================================================
>> ==========
>> >>>>>>
>> >>>>>> Suggested solution:
>> >>>>>>
>> --------------------------------------------------------------
>> ----------
>> >>>>>>
>> >>>>>>   change anonymization requirement in section 6.7 from
>> MAY to MUST
>> >>>>>>
>> ==============================================================
>> ==========
>> >>>>>>
>> >>>>>> Status: solution to be agreed on
>> >>>>>>
>> ==============================================================
>> ==========
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Again, I have the same type of comments. Anonymization
>> is not required
>> >>>>> in all cases. So why make it a MUST?
>> >>>>>
>> >>>>> 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/
>> >>>>
>> >>>
>> >>>
>> >>> --
>> >>> Sebastian Zander                         E-mail:
>> >>> zander@fokus.fraunhofer.de
>> >>> Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
>> >>> Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
>> >>> D-10589 Berlin, Germany
>> >>> www.fokus.fraunhofer.de/usr/sebastian.zander
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > Sebastian Zander                         E-mail:
>> zander@fokus.fraunhofer.de
>> > Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
>> > Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
>> > D-10589 Berlin, Germany
>> www.fokus.fraunhofer.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/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun  2 05:20:28 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29254
	for <ipfix-archive@lists.ietf.org>; Mon, 2 Jun 2003 05:20:28 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Ml4y-00031j-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 02 Jun 2003 03:54:08 -0500
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Ml4v-00031Y-00
	for ipfix@net.doit.wisc.edu; Mon, 02 Jun 2003 03:54:05 -0500
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h528rmVI039375;
	Mon, 2 Jun 2003 10:53:51 +0200 (CEST)
Received: from [10.1.1.128] (n-quittek.office [10.1.1.128])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 416C2A8A67; Mon,  2 Jun 2003 10:42:06 +0200 (CEST)
Date: Mon, 02 Jun 2003 10:55:57 +0200
From: Juergen Quittek <quittek@ccrle.nec.de>
To: Ganesh Sadasivan <gsadasiv@cisco.com>
Cc: ipfix@net.doit.wisc.edu
Subject: Re: Observation Domain [ Was Re: [ipfix] Changes to architecture doc.]
Message-ID: <7519212.1054551357@[10.1.1.128]>
In-Reply-To: <3ED77965.4012EF7@cisco.com>
References:  <3ED77965.4012EF7@cisco.com>
X-Mailer: Mulberry/2.1.2 (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 <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Ganesh,

Thank you for drawing the figure below. Although you say that there are
only slight modifications, to me they are important. I fully agree to
the new figure. Now, the observation domain really is a functional block
not including observation points, but associated with a set of
observation points.

I still do not like the terminology, because we call a functional block
a 'domain'. This is a minor issue, but anyway here is a suggestion:

In your figure below, the box called 'observation domain' is a
functional block. What about calling it 'flow recording process'
or similarly. Then you could declare the 'observation domain' of
of a flow recording process to be the set of observation points
associated with this flow recording process.

Cheers,

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


-- Ganesh Sadasivan wrote on 30 May 2003 08:31 -0700:

> Juergen,
>
>
> Juergen Quittek wrote:
>
>> Ganesh
>>
>> -- Ganesh Sadasivan wrote on 16 May 2003 14:35 -0700:
>>
>> > * Section 4.3 Observation Domain
>> > Functions of Observation domain.
>> > " * Encoding the flow records and sending them to the export process.
>> >   * Encoding the control information into templates and sending them to
>> >   the export process."
>> > The above 2 are already covered by IPFIX protocol.
>> >
>> > "  * Deciding which flow records/control information to export using
>> >      rules based on time, thresholds, configuration events etc.
>> >    * Aggregating flow records generated by one or more metering
>> >      processes."
>> > The above 2 are also IPFIX protocol function. So also is flow
>> > expiration.
>> >
>> > Observation point is a logical block which maintains flows for a
>>
>> Here you mean observation domain, not observation point.
>
> Yes. sorry for the confusion.
>
>>
>>
>> > a set of {observation point, metering process} (in a database form)
>> > and maintains aggregate statistics. All the other flow related
>> > functions should be handled by IPFIX protocol and metering process.
>> >
>>
>> I have a problem with the concept of an observation domain.  You say it
>> is a 'functional block', but in the figure it includes observation points
>> which are locations in the network and no functional blocks.  So the
>> concept of the observation domain is not a clean one.  I see an observation
>> domain as a useful concept for implementation design of IPFIX on a
>> device with multiple line cards, but not useful for the general IPFIX
>> architecture.
>
> The idea is to present a single identity for a group of observation points
> to the exporter. That is why it is mentioned as a logical block which
> encompasses a set of observation points. It does not matter whether the
> observation points are in a single board or different board or even different
> nodes. It is a question as to how the collector identifies a group of observation
>
> points.
> Ofcourse a degenrate case is a single observation point in an observation
> domain.
>
>>
>>
>> Also I do not see a reason, why the general architecture should define
>> an internal function block for "sending them [flow records] from [the
>> metering process] to the exporting process".  Why sending them, if they
>> are co-located?  Whether or not you locate metering process and exporting
>> process on different boards and need to send them over an internal bus
>> is a detail of an implementation design, but IMHO should not be part
>> of the general IPFIX architecture. And we are definitely not defining
>> a netwrok protocol between metering process and exporting process.
>>
>
> I am copying the figure down once again with slight modifications for clarity
> and please explain how this restricts to a class of implementtations.
>
>    +-----------------------------+-------------------------------------+
>    |              packet header capturing                              |
>    |                             |               METERING PROCESS      |
>    |                        timestamping         on an                 |
>    |                             |               observation point     |
>    |                             v                                     |
>    |                      +----->+                                     |
>    |                      |      |                                     |
>    |                      |   sampling Si (1:1 in case of no sampling) |
>    |                      |      |                                     |
>    |                      | classifying Fi (NULL when No criteria)     |
>    |                      |      |                                     |
>    |                      +------+                                     |
>    |                             |                                     |
>    +-----------------------------+-------------------------------------+
>                                  |
>                                  v                                      .
>                                Flows                                    .
>                                  +--------------------------------------+...
>                                  |
>                                  |
>    +-----------------------------+----------------------------------------+
>    |                             V    OBSERVATION DOMAIN                  |
>    |             +----------------------+         +------------------+    |
>    |             | Flow data base       |<--------|Provide non-flow  |    |
>    |             | (includes flows      |         | information (Eg. |    |
>    |             | from all obs.        |         | router state)    |    |
>    |             | points in an obs.    |         +------------------+    |
>    |             | domain)              |                                 |
>    |             |                      |         +------------------+    |
>    |             |                      |<--------|Maintain aggregate|    |
>    |             |                      |         | statistics       |    |
>    |             +----------------------+         +------------------+    |
>    |                                                                      |
>    +-----------------------------+----------------------------------------+
>                                  |
>                             Flow Database (identified by observation domain)
>    +-----------------------------+----------------------------------------+
>    |                             V    IPFIX PROTOCOL                      |
>    |             +----------------------+                                 |
>    |             | Rules for 1. picking&|                                 |
>    |             | sending templates    |                                 |
>    |             | 2.picking& sending   |                                 |
>    |             | data records 3. timi-|                                 |
>    |             | out flows 4. Encoding|                                 |
>    |             | template & data.     |                                 |
>    |             |                      |                                 |
>    |             |                      |                                 |
>    |             |                      |                                 |
>    |             +----------------------+                                 |
>    |                                                                      |
>    +----------------------------------------------------------------------+
>
>>
>> The requirements do intentionally not discuss how flow records are
>> shared between metering process and exporting process, because there
>> are many different potential hardware and software device architectures
>> that require different ways of communication between these processes.
>> I do not think the IPFIX architecture should request that the there
>> is an instance sending flow records from one process to the other,
>> because there are several alternatives which would become excluded
>> without need, for example shared memory (including remote memory access
>> from the exporter to a metering card).
>>
>
>  The idea is that any  function mentioned in the figure above
> as part of an observation domain is optional, but if such a functionality exists,
>
> it exists in the context of an observation domain. It is like pieces in a
> metering
> process. Not every one would want to do sampling and classifying. But they
> are still listed as part of metering.
>
>>
>> In the requirements document we mapped requirements concerning the
>> reports to the collecting process (for example the reporting period)
>> to the section of requirements for the exporting process. Consequently,
>> I would see several of the functions you listed for the observation
>> records as part of the exporting process (for example generating templates).
>
> If you are refering to section 4.3 of the arch. spec, yes they specify functions
> which
> are not done by the observation domain. I had mentioned in my first e-mail
> on this topic
> "> * Section 4.3 Observation Domain
>   > Functions of Observation domain.
>   > " * Encoding the flow records and sending them to the export process.
>   >   * Encoding the control information into templates and sending them to
>   >   the export process."
>   > The above 2 are already covered by IPFIX protocol.
>   > "  * Deciding which flow records/control information to export using
>   >      rules based on time, thresholds, configuration events etc.
>   >    * Aggregating flow records generated by one or more metering
>   >      processes."
>   > The above 2 are also IPFIX protocol function. So also is flow
>   > expiration. "
> But then we have to mention that IPFIX protocol happens in the context of
> export process.
>
>>
>>
>> For all these reasons I suggest to use the following maping of functions
>> to metering process and exporting process.
>>
>> The metering process is a process triggered by packet arrival. It performs
>> time critical wire-speed processing of packets and creating/updating of
>> the corresponding flow records.
>>
>> Compared to the metering process, the export process is a rather low speed
>> process triggered by flow timeouts and reporting interval timers (and
>> probably by some other events). It encodes flow records into packets,
>> generates templates and sends everything securely to the collecting process.
>>
>
> Agreed.
>
>>
>> Now, coming back to the point that probably was a motivation for inventing
>> the observation domain:  If you want to split the exporting process in
>> a portion that acts on router line cards (generating templetes and reports
>> and a part acting on the central processor board of a router (securely
>> exporting all reports generated on different line cards), then I suggest
>> to split the exporting process (as defined in the requirements) into a
>> reporting process and sending process (you might like to change terms).
>
> If observation domain were to do functions in 4.3 yes then there a good reason.
> But IMO is not the function of observation domain. As far the export process
> is concerened (which includes the IPFIX protocol), itcan be split the way
> you mentioned above. But not mentioning this explicitly does not limit the
> implementation on distributed systems (or does it?) .
>
> Thanks
> Ganesh
>
>>
>
>>
>>
>> Then the chain of observation point, metering process and exporting
>> process
>>
>>   O - M - E
>>
>> would then be replaced by the chain observation point, metering process,
>> reporitng process and sending process
>>
>>   O - M - R - S
>>
>> Advantages:
>>   - it is in line with the requirements
>>   - it is consistent (not merging functions and locations)
>>   - it still allows you to place parts of the exporting
>>     process on line cards, while the rest remains central
>>   - it is much in line with the PSAMP architecture
>>     increasing synergy between both WGs
>>
>> Cheers,
>>
>>     Juergen
>> --
>> Juergen Quittek        quittek@ccrle.nec.de        Tel: +49 6221 90511-15
>> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
>> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
>>
>> --
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" 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 Jun  2 06:42:41 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01056
	for <ipfix-archive@lists.ietf.org>; Mon, 2 Jun 2003 06:42:40 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19MmYa-0005oE-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 02 Jun 2003 05:28:48 -0500
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 19MmYZ-0005o7-00
	for ipfix@net.doit.wisc.edu; Mon, 02 Jun 2003 05:28:47 -0500
Received: from cisco.com (dhcp-peg3-vl30-144-254-7-130.cisco.com [144.254.7.130])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h52ASLR05297;
	Mon, 2 Jun 2003 12:28:21 +0200 (CEST)
Message-ID: <3EDB26C3.40701@cisco.com>
Date: Mon, 02 Jun 2003 12:28:19 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Juergen Quittek <quittek@ccrle.nec.de>
CC: Tal Givoly <givoly@xacct.com>, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] IPFIX requirements - final changes
References: <DLEIIIOHMNPJPNMKGEFDAEEBDJAA.givoly@xacct.com> <3758163.1054116399@[10.1.1.128]>
In-Reply-To: <3758163.1054116399@[10.1.1.128]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Juergen,

> Tal, Reinaldo, and Benoit,
>
> Do we all have the following in mind?
>
>   Anonymization and confidentiality MUST be covered by the
>   protocol specification.  But the protocol specifiction
>   specification defines it as a MAY feature (anonymization)
>   or SHOULD feature (confidentiality) for IPFIX protocol
>   implementations. 

Yes, absolutely.

Regards, Benoit.


>
>
> I guess this is what the IESG reviewers were referring to.
>
> What is probably missing in the requirements document is a
> statement like the following:
>
>   Many requirements in this document are not explicitly
>   stated as IPFIX protocol requirements, but as requirements
>   for the metering process, the exporting process, or for
>   other traffic measurement components. However, every
>   requirement that needs support from the IPFIX protocol
>   MUST be covered by the IPFIX protocol specification
>   independent of the significance of the requirement,
>   which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
>   Note that the protocol specification itself also assigns
>   significance attributes to its features, such that a
>   protocol implementation does not necessarily need to
>   implement all features.
>
> Any comment on this?
>
>    Juergen
>
>
> -- Tal Givoly wrote on 26 May 2003 09:42 -0700:
>
>> Juergen,
>>
>> I agree with Benoit - it doesn't make sense to make confidentiality and
>> anonymization mandatory. In many deployments, there could be physical 
>> and
>> other security measures that addresses these issues.
>>
>> Tal
>>
>> -----Original Message-----
>> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
>> Of Benoit Claise
>> Sent: Monday, May 26, 2003 8:02 AM
>> To: Juergen Quittek
>> Cc: ipfix@net.doit.wisc.edu
>> Subject: Re: [ipfix] IPFIX requirements - final changes
>>
>>
>> Juergen,
>>
>>> ========================================================================
>>> 12. Confidentiality from SHOULD to MUST
>>> ========================================================================
>>> Problem Description:
>>> ------------------------------------------------------------------------
>>> Requirements on the ipfix implementation - the document is long and I
>>> wonder if
>>> the working group really meant the protocol's confidentiality and
>>> anonymization
>>> features to be so optional -  SHOULD confidentiality, MAY 
>>> anonymization.
>>> Just for implementation.
>>> ========================================================================
>>> Suggested solution:
>>> ------------------------------------------------------------------------
>>>   change confidentiality requirement in section 6.3.3
>>>   from SHOULD to MUST
>>> ========================================================================
>>> Status: solution to be agreed on
>>> ========================================================================
>>
>>
>> I'm just wondering if a MUST is not a little bit extreme.
>> The draft would become:
>>    "Confidentiality of flow specific data transferred from an exporting
>>    process to a collecting process MUST be ensured."
>> We all agree that over the Internet confidentiality is compulsory but
>> this sentence would mean that even in a private LAN or environment, we
>> must have confidentiality to be IPFIX compliant. And we know that, with
>> the software based encryption, the throughput would be lowered. Ok, then
>> we should have an crypto engine in hardware on the exporter to export
>> the numerous flow export packets but there is a price to it.
>> My point is that, as Confidentiality is not needed in all cases, why
>> make it a MUST?
>>
>>>
>>>
>>>
>>> ========================================================================
>>> 13. Anonymization from MAY to MUST
>>> ========================================================================
>>> Problem Description:
>>> ------------------------------------------------------------------------
>>> Requirements on the ipfix implementation - the document is long and I
>>> wonder if
>>> the working group really meant the protocol's confidentiality and
>>> anonymization
>>> features to be so optional -  SHOULD confidentiality, MAY 
>>> anonymization.
>>> Just for implementation.
>>> ========================================================================
>>> Suggested solution:
>>> ------------------------------------------------------------------------
>>>   change anonymization requirement in section 6.7 from MAY to MUST
>>> ========================================================================
>>> Status: solution to be agreed on
>>> ========================================================================
>>
>>
>> Again, I have the same type of comments. Anonymization is not required
>> in all cases. So why make it a MUST?
>>
>> 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 Jun  2 06:44:12 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01097
	for <ipfix-archive@lists.ietf.org>; Mon, 2 Jun 2003 06:44:12 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19MmYd-0005oO-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 02 Jun 2003 05:28:51 -0500
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 19MmYb-0005oH-00
	for ipfix@net.doit.wisc.edu; Mon, 02 Jun 2003 05:28:49 -0500
Received: from cisco.com (dhcp-peg3-vl30-144-254-7-130.cisco.com [144.254.7.130])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h52ASaR05580;
	Mon, 2 Jun 2003 12:28:36 +0200 (CEST)
Message-ID: <3EDB26D2.1090103@cisco.com>
Date: Mon, 02 Jun 2003 12:28:34 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sebastian Zander <zander@fokus.fraunhofer.de>
CC: Juergen Quittek <quittek@ccrle.nec.de>, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] IPFIX requirements - final changes
References: <DLEIIIOHMNPJPNMKGEFDAEEBDJAA.givoly@xacct.com> <3758163.1054116399@[10.1.1.128]> <3ED48D12.9030603@fokus.fraunhofer.de>
In-Reply-To: <3ED48D12.9030603@fokus.fraunhofer.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Sebastian,

> But i do *not* agree at all that in general anonymization and
> confidentiality is not needed in a LAN. Anonymization can be required
> in a LAN and even in a LAN confidentiality may be needed because i
> don't want everybody who has access to my LAN to have access to my
> IPFIX data. 

I think that I caused this reaction by my first email on this topic.
Obviously, you are right that it might be needed in a LAN environment!
My point was not to deduce generic situations where we need/don't need 
anonymization/confidentiality.
I wanted to stress that it must be left open to the implementors.
And I think we all agree on this point.

Regards, Benoit.

>
>
> Cheers,
>
> Sebastian
>
> Juergen Quittek wrote:
>
>> Tal, Reinaldo, and Benoit,
>>
>> Do we all have the following in mind?
>>
>>   Anonymization and confidentiality MUST be covered by the
>>   protocol specification.  But the protocol specifiction
>>   specification defines it as a MAY feature (anonymization)
>>   or SHOULD feature (confidentiality) for IPFIX protocol
>>   implementations.
>>
>> I guess this is what the IESG reviewers were referring to.
>>
>> What is probably missing in the requirements document is a
>> statement like the following:
>>
>>   Many requirements in this document are not explicitly
>>   stated as IPFIX protocol requirements, but as requirements
>>   for the metering process, the exporting process, or for
>>   other traffic measurement components. However, every
>>   requirement that needs support from the IPFIX protocol
>>   MUST be covered by the IPFIX protocol specification
>>   independent of the significance of the requirement,
>>   which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
>>   Note that the protocol specification itself also assigns
>>   significance attributes to its features, such that a
>>   protocol implementation does not necessarily need to
>>   implement all features.
>>
>> Any comment on this?
>>
>>    Juergen
>>
>>
>> -- Tal Givoly wrote on 26 May 2003 09:42 -0700:
>>
>>> Juergen,
>>>
>>> I agree with Benoit - it doesn't make sense to make confidentiality and
>>> anonymization mandatory. In many deployments, there could be 
>>> physical and
>>> other security measures that addresses these issues.
>>>
>>> Tal
>>>
>>> -----Original Message-----
>>> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On 
>>> Behalf
>>> Of Benoit Claise
>>> Sent: Monday, May 26, 2003 8:02 AM
>>> To: Juergen Quittek
>>> Cc: ipfix@net.doit.wisc.edu
>>> Subject: Re: [ipfix] IPFIX requirements - final changes
>>>
>>>
>>> Juergen,
>>>
>>>> ========================================================================
>>>> 12. Confidentiality from SHOULD to MUST
>>>> ========================================================================
>>>> Problem Description:
>>>> ------------------------------------------------------------------------
>>>> Requirements on the ipfix implementation - the document is long and I
>>>> wonder if
>>>> the working group really meant the protocol's confidentiality and
>>>> anonymization
>>>> features to be so optional -  SHOULD confidentiality, MAY 
>>>> anonymization.
>>>> Just for implementation.
>>>> ========================================================================
>>>> Suggested solution:
>>>> ------------------------------------------------------------------------
>>>>   change confidentiality requirement in section 6.3.3
>>>>   from SHOULD to MUST
>>>> ========================================================================
>>>> Status: solution to be agreed on
>>>> ========================================================================
>>>
>>>
>>>
>>> I'm just wondering if a MUST is not a little bit extreme.
>>> The draft would become:
>>>    "Confidentiality of flow specific data transferred from an exporting
>>>    process to a collecting process MUST be ensured."
>>> We all agree that over the Internet confidentiality is compulsory but
>>> this sentence would mean that even in a private LAN or environment, we
>>> must have confidentiality to be IPFIX compliant. And we know that, with
>>> the software based encryption, the throughput would be lowered. Ok, 
>>> then
>>> we should have an crypto engine in hardware on the exporter to export
>>> the numerous flow export packets but there is a price to it.
>>> My point is that, as Confidentiality is not needed in all cases, why
>>> make it a MUST?
>>>
>>>>
>>>>
>>>>
>>>> ========================================================================
>>>> 13. Anonymization from MAY to MUST
>>>> ========================================================================
>>>> Problem Description:
>>>> ------------------------------------------------------------------------
>>>> Requirements on the ipfix implementation - the document is long and I
>>>> wonder if
>>>> the working group really meant the protocol's confidentiality and
>>>> anonymization
>>>> features to be so optional -  SHOULD confidentiality, MAY 
>>>> anonymization.
>>>> Just for implementation.
>>>> ========================================================================
>>>> Suggested solution:
>>>> ------------------------------------------------------------------------
>>>>   change anonymization requirement in section 6.7 from MAY to MUST
>>>> ========================================================================
>>>> Status: solution to be agreed on
>>>> ========================================================================
>>>
>>>
>>>
>>> Again, I have the same type of comments. Anonymization is not required
>>> in all cases. So why make it a MUST?
>>>
>>> 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/
>>
>
>



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun  2 07:08:50 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01361
	for <ipfix-archive@lists.ietf.org>; Mon, 2 Jun 2003 07:08:49 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Mmo5-0006GG-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 02 Jun 2003 05:44:49 -0500
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 19Mmny-0006Fx-00
	for ipfix@net.doit.wisc.edu; Mon, 02 Jun 2003 05:44:46 -0500
Received: from cisco.com (dhcp-peg3-vl30-144-254-7-130.cisco.com [144.254.7.130])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h52AheR24239;
	Mon, 2 Jun 2003 12:43:40 +0200 (CEST)
Message-ID: <3EDB2A5B.7070302@cisco.com>
Date: Mon, 02 Jun 2003 12:43:39 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Juergen Quittek'" <quittek@ccrle.nec.de>,
        Sebastian Zander <zander@fokus.fraunhofer.de>, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] IPFIX requirements - final changes
References: <1D3D2C371FCBD947A7897FABBD3533A50295FFEB@xsun01.ptp.hp.com>
In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A50295FFEB@xsun01.ptp.hp.com>
Content-Type: multipart/alternative;
 boundary="------------070303020406040004050803"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.
--------------070303020406040004050803
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Jeff,

>  Your phrasing sounds good:
>
> "Many requirements in this document are not explicitly
>  stated as IPFIX protocol requirements, but as requirements
>  for the metering process, the exporting process, or for
>  other traffic measurement components. However, every
>  requirement that needs support from the IPFIX protocol
>  MUST be covered by the IPFIX protocol specification
>  independent of the significance of the requirement,
>  which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
>  Note that the protocol specification itself also assigns
>  significance attributes to its features, such that a
>  protocol implementation does not necessarily need to
>  implement all features."
>
>  One change I would suggest is to recognize that the specification
>contains both a protocol and an (extendable) information model.
>E.g. anonymization can be addressed w/o any change to the
>protocol.
>
>  So I'd rather see one of the sentences modified as:
>
>    However, every requirement that needs support from the 
>  IPFIX protocol or information model MUST be covered by the 
>  IPFIX protocol or information model specification
>  independent of the significance of the requirement
>
You have a good point.
Now, I'm thinking loud here.
Aren't they any requirements that influence the architecture draft?
So should we have this sentence more generic? And as a consequence 
include a pointer to the architecture draft?
I think this is worth mentioning.

So this paragraph would become (at least regarding the meaning):

    However, every requirement that needs support from one or multiple drafts (IPFIX architecture, I PFIX protocol, information model) MUST be covered by the respective specification
    independent of the significance of the requirement

Regards, Benoit.


>
>Regards,
>
>  Jeff Meyer
>
>  
>
>>-----Original Message-----
>>From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>>Sent: Friday, May 30, 2003 5:50 AM
>>To: Sebastian Zander
>>Cc: ipfix@net.doit.wisc.edu
>>Subject: Re: [ipfix] IPFIX requirements - final changes
>>
>>
>>Sebastian,
>>
>>-- Sebastian Zander wrote on 29 May 2003 03:29 +0200:
>>
>>    
>>
>>>Juergen,
>>>
>>>Juergen Quittek wrote:
>>>      
>>>
>>>>Sebastian,
>>>>
>>>>-- Sebastian Zander wrote on 28 May 2003 12:18 +0200:
>>>>
>>>>        
>>>>
>>>>>Hi Juergen,
>>>>>
>>>>>i think your second paragraph is a very good idea. But i don't
>>>>>understand the last 2 sentences. My understanding is that 
>>>>>          
>>>>>
>>the ipfix
>>    
>>
>>>>>requirement draft defines the ipfix protocol 
>>>>>          
>>>>>
>>requirements. So i don't
>>    
>>
>>>>>understand why the protocol specification must cover all 
>>>>>          
>>>>>
>>requirements.
>>    
>>
>>>>>E.g. when a requirementis optional why must it be covered 
>>>>>          
>>>>>
>>in the protocol
>>    
>>
>>>>>specification?
>>>>>          
>>>>>
>>>>If the requirement doc says "the exporter MAY anonymize", then the
>>>>protocol specification MUST support anonymization in order to make
>>>>sure, that anonymization is interoperable. For example the protocol
>>>>spec MUST define how to inform a collecting process that 
>>>>        
>>>>
>>the data it
>>    
>>
>>>>receives is anonymized. Analogously, the protocol spec 
>>>>        
>>>>
>>should specify
>>    
>>
>>>>how to encrypt.
>>>>
>>>>In both cases, the protocol specification can state that a concrete
>>>>implementation of the protocol MAY support features that serve
>>>>anonymization. Then an implementor can choose whether or 
>>>>        
>>>>
>>not to implement
>>    
>>
>>>>this OPTIONAL feature of the protocol.
>>>>        
>>>>
>>>You are right. The req draft contains protocol 
>>>      
>>>
>>specification requirements
>>    
>>
>>>(which is sometimes confusing and the reason why we get 
>>>      
>>>
>>those comments).
>>    
>>
>>>But i suggest to change the middle sentence saying that all protocol
>>>specification requirements from the req draft must be taken 
>>>      
>>>
>>over into the
>>    
>>
>>>protocol draft *including their significance*. Otherwise 
>>>      
>>>
>>why do we spend a
>>    
>>
>>>long time discussing the significance of some reqs if it is 
>>>      
>>>
>>not used later
>>    
>>
>>>in the protocol draft? Furthermore some of the reqs may be 
>>>      
>>>
>>targeting the
>>    
>>
>>>information model or achitecture draft instead of the 
>>>      
>>>
>>protocol spec. So
>>    
>>
>>>the sentence should not only mention the protocol spec but *also the
>>>information model etc*. (Jeff just gave an example that 
>>>      
>>>
>>anonymization may
>>    
>>
>>>influence the information model.)
>>>      
>>>
>>I see your point, but I would suggest a different phrasing for the
>>following reason:
>>  - I do not expect that requirement items can be mapped 
>>one-to-one onto
>>    protocol features. Some individual protocol feature will 
>>cover several
>>    requirement items at once. So here you cannot map the significance
>>    one-to-one, but need something like a minimum significance to be
>>    considered.
>>  - My experience from designing other protocols is that - 
>>compared to the
>>    requirements - you usually increase significance of some features
>>    for technical or orther reasons. We must make sure that 
>>the protocol
>>    definition process has this level of freedom.
>>
>>Therefore, I suggest to extend my initially suggested paragraph
>>
>> "Many requirements in this document are not explicitly
>>  stated as IPFIX protocol requirements, but as requirements
>>  for the metering process, the exporting process, or for
>>  other traffic measurement components. However, every
>>  requirement that needs support from the IPFIX protocol
>>  MUST be covered by the IPFIX protocol specification
>>  independent of the significance of the requirement,
>>  which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
>>  Note that the protocol specification itself also assigns
>>  significance attributes to its features, such that a
>>  protocol implementation does not necessarily need to
>>  implement all features."
>>
>>by appending this sentence or a similar one:
>>
>> "However, the significance assigned to a protocol feature
>>  MUST NOT be lower than the significance of the corresponding
>>  requirements."
>>
>>Cheers,
>>
>>    Juergen
>>
>>
>>    
>>
>>>This statement must be put in the very beginning of the req draft.
>>>
>>>The last sentence is not necessary in my opinion because 
>>>      
>>>
>>its pretty obvious
>>    
>>
>>>that the protocol draft and the other drafts will use more (and more
>>>detailed) reqs.
>>>
>>>Then there is no need to change the requirements to MUST.
>>>
>>>Cheers,
>>>
>>>Sebastian
>>>
>>>      
>>>
>>>>>I agree to say its a MUST for the protocol but not all exporters
>>>>>and collectors must support it.
>>>>>          
>>>>>
>>>>Agreed.
>>>>
>>>>        
>>>>
>>>>>But i do *not* agree at all that in general anonymization and
>>>>>confidentiality is not needed in a LAN. Anonymization can 
>>>>>          
>>>>>
>>be required
>>    
>>
>>>>>in a LAN and even in a LAN confidentiality may be needed because i
>>>>>don't want everybody who has access to my LAN to have access to my
>>>>>IPFIX data.
>>>>>          
>>>>>
>>>>Also agreed.
>>>>
>>>>Best wishes,
>>>>
>>>>   Juergen
>>>>
>>>>        
>>>>
>>>>>Cheers,
>>>>>
>>>>>Sebastian
>>>>>
>>>>>Juergen Quittek wrote:
>>>>>
>>>>>          
>>>>>
>>>>>>Tal, Reinaldo, and Benoit,
>>>>>>
>>>>>>Do we all have the following in mind?
>>>>>>
>>>>>>  Anonymization and confidentiality MUST be covered by the
>>>>>>  protocol specification.  But the protocol specifiction
>>>>>>  specification defines it as a MAY feature (anonymization)
>>>>>>  or SHOULD feature (confidentiality) for IPFIX protocol
>>>>>>  implementations.
>>>>>>
>>>>>>I guess this is what the IESG reviewers were referring to.
>>>>>>
>>>>>>What is probably missing in the requirements document is a
>>>>>>statement like the following:
>>>>>>
>>>>>>  Many requirements in this document are not explicitly
>>>>>>  stated as IPFIX protocol requirements, but as requirements
>>>>>>  for the metering process, the exporting process, or for
>>>>>>  other traffic measurement components. However, every
>>>>>>  requirement that needs support from the IPFIX protocol
>>>>>>  MUST be covered by the IPFIX protocol specification
>>>>>>  independent of the significance of the requirement,
>>>>>>  which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
>>>>>>  Note that the protocol specification itself also assigns
>>>>>>  significance attributes to its features, such that a
>>>>>>  protocol implementation does not necessarily need to
>>>>>>  implement all features.
>>>>>>
>>>>>>Any comment on this?
>>>>>>
>>>>>>   Juergen
>>>>>>
>>>>>>
>>>>>>-- Tal Givoly wrote on 26 May 2003 09:42 -0700:
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>Juergen,
>>>>>>>
>>>>>>>I agree with Benoit - it doesn't make sense to make 
>>>>>>>              
>>>>>>>
>>confidentiality and
>>    
>>
>>>>>>>anonymization mandatory. In many deployments, there could be
>>>>>>>physical and
>>>>>>>other security measures that addresses these issues.
>>>>>>>
>>>>>>>Tal
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: majordomo listserver 
>>>>>>>              
>>>>>>>
>>[mailto:majordomo@mil.doit.wisc.edu]On
>>    
>>
>>>>>>>Behalf
>>>>>>>Of Benoit Claise
>>>>>>>Sent: Monday, May 26, 2003 8:02 AM
>>>>>>>To: Juergen Quittek
>>>>>>>Cc: ipfix@net.doit.wisc.edu
>>>>>>>Subject: Re: [ipfix] IPFIX requirements - final changes
>>>>>>>
>>>>>>>
>>>>>>>Juergen,
>>>>>>>
>>>>>>>              
>>>>>>>
>>==============================================================
>>==========
>>    
>>
>>>>>>>>12. Confidentiality from SHOULD to MUST
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>==============================================================
>>==========
>>    
>>
>>>>>>>>Problem Description:
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>--------------------------------------------------------------
>>----------
>>    
>>
>>>>>>>>Requirements on the ipfix implementation - the 
>>>>>>>>                
>>>>>>>>
>>document is long and I
>>    
>>
>>>>>>>>wonder if
>>>>>>>>the working group really meant the protocol's 
>>>>>>>>                
>>>>>>>>
>>confidentiality and
>>    
>>
>>>>>>>>anonymization
>>>>>>>>features to be so optional -  SHOULD confidentiality, MAY
>>>>>>>>anonymization.
>>>>>>>>Just for implementation.
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>==============================================================
>>==========
>>    
>>
>>>>>>>>Suggested solution:
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>--------------------------------------------------------------
>>----------
>>    
>>
>>>>>>>>  change confidentiality requirement in section 6.3.3
>>>>>>>>  from SHOULD to MUST
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>==============================================================
>>==========
>>    
>>
>>>>>>>>Status: solution to be agreed on
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>==============================================================
>>==========
>>    
>>
>>>>>>>
>>>>>>>I'm just wondering if a MUST is not a little bit extreme.
>>>>>>>The draft would become:
>>>>>>>   "Confidentiality of flow specific data transferred 
>>>>>>>              
>>>>>>>
>>from an exporting
>>    
>>
>>>>>>>   process to a collecting process MUST be ensured."
>>>>>>>We all agree that over the Internet confidentiality is 
>>>>>>>              
>>>>>>>
>>compulsory but
>>    
>>
>>>>>>>this sentence would mean that even in a private LAN or 
>>>>>>>              
>>>>>>>
>>environment, we
>>    
>>
>>>>>>>must have confidentiality to be IPFIX compliant. And we 
>>>>>>>              
>>>>>>>
>>know that, with
>>    
>>
>>>>>>>the software based encryption, the throughput would be 
>>>>>>>              
>>>>>>>
>>lowered. Ok,
>>    
>>
>>>>>>>then
>>>>>>>we should have an crypto engine in hardware on the 
>>>>>>>              
>>>>>>>
>>exporter to export
>>    
>>
>>>>>>>the numerous flow export packets but there is a price to it.
>>>>>>>My point is that, as Confidentiality is not needed in 
>>>>>>>              
>>>>>>>
>>all cases, why
>>    
>>
>>>>>>>make it a MUST?
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>==============================================================
>>==========
>>    
>>
>>>>>>>>13. Anonymization from MAY to MUST
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>==============================================================
>>==========
>>    
>>
>>>>>>>>Problem Description:
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>--------------------------------------------------------------
>>----------
>>    
>>
>>>>>>>>Requirements on the ipfix implementation - the 
>>>>>>>>                
>>>>>>>>
>>document is long and I
>>    
>>
>>>>>>>>wonder if
>>>>>>>>the working group really meant the protocol's 
>>>>>>>>                
>>>>>>>>
>>confidentiality and
>>    
>>
>>>>>>>>anonymization
>>>>>>>>features to be so optional -  SHOULD confidentiality, MAY
>>>>>>>>anonymization.
>>>>>>>>Just for implementation.
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>==============================================================
>>==========
>>    
>>
>>>>>>>>Suggested solution:
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>--------------------------------------------------------------
>>----------
>>    
>>
>>>>>>>>  change anonymization requirement in section 6.7 from 
>>>>>>>>                
>>>>>>>>
>>MAY to MUST
>>    
>>
>>==============================================================
>>==========
>>    
>>
>>>>>>>>Status: solution to be agreed on
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>==============================================================
>>==========
>>    
>>
>>>>>>>
>>>>>>>Again, I have the same type of comments. Anonymization 
>>>>>>>              
>>>>>>>
>>is not required
>>    
>>
>>>>>>>in all cases. So why make it a MUST?
>>>>>>>
>>>>>>>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/
>>>>>>
>>>>>>            
>>>>>>
>>>>>--
>>>>>Sebastian Zander                         E-mail:
>>>>>zander@fokus.fraunhofer.de
>>>>>Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
>>>>>Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
>>>>>D-10589 Berlin, Germany
>>>>>www.fokus.fraunhofer.de/usr/sebastian.zander
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>
>>>>        
>>>>
>>>--
>>>Sebastian Zander                         E-mail: 
>>>      
>>>
>>zander@fokus.fraunhofer.de
>>    
>>
>>>Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
>>>Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
>>>D-10589 Berlin, Germany                  
>>>      
>>>
>>www.fokus.fraunhofer.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/
>  
>


--------------070303020406040004050803
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Jeff,<br>
<blockquote type="cite"
 cite="mid1D3D2C371FCBD947A7897FABBD3533A50295FFEB@xsun01.ptp.hp.com">
  <pre wrap="">
  Your phrasing sounds good:

 "Many requirements in this document are not explicitly
  stated as IPFIX protocol requirements, but as requirements
  for the metering process, the exporting process, or for
  other traffic measurement components. However, every
  requirement that needs support from the IPFIX protocol
  MUST be covered by the IPFIX protocol specification
  independent of the significance of the requirement,
  which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
  Note that the protocol specification itself also assigns
  significance attributes to its features, such that a
  protocol implementation does not necessarily need to
  implement all features."

  One change I would suggest is to recognize that the specification
contains both a protocol and an (extendable) information model.
E.g. anonymization can be addressed w/o any change to the
protocol.

  So I'd rather see one of the sentences modified as:

    However, every requirement that needs support from the 
  IPFIX protocol or information model MUST be covered by the 
  IPFIX protocol or information model specification
  independent of the significance of the requirement</pre>
</blockquote>
You have a good point.<br>
Now, I'm thinking loud here.<br>
Aren't they any requirements that influence the architecture draft?<br>
So should we have this sentence more generic? And as a consequence
include a pointer to the architecture draft?<br>
I think this is worth mentioning.<br>
<br>
So this paragraph would become (at least regarding the meaning):<br>
<pre wrap="">    However, every requirement that needs support from one or multiple drafts (IPFIX architecture, I PFIX protocol, information model) MUST be covered by the<span
 class="moz-txt-citetags"></span> respective specification
<span class="moz-txt-citetags"> </span>   independent of the significance of the requirement
</pre>
Regards, Benoit.<br>
<br>
<br>
<blockquote type="cite"
 cite="mid1D3D2C371FCBD947A7897FABBD3533A50295FFEB@xsun01.ptp.hp.com">
  <pre wrap="">

Regards,

  Jeff Meyer

  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----
From: Juergen Quittek [<a class="moz-txt-link-freetext" href="mailto:quittek@ccrle.nec.de">mailto:quittek@ccrle.nec.de</a>]
Sent: Friday, May 30, 2003 5:50 AM
To: Sebastian Zander
Cc: <a class="moz-txt-link-abbreviated" href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a>
Subject: Re: [ipfix] IPFIX requirements - final changes


Sebastian,

-- Sebastian Zander wrote on 29 May 2003 03:29 +0200:

    </pre>
    <blockquote type="cite">
      <pre wrap="">Juergen,

Juergen Quittek wrote:
      </pre>
      <blockquote type="cite">
        <pre wrap="">Sebastian,

-- Sebastian Zander wrote on 28 May 2003 12:18 +0200:

        </pre>
        <blockquote type="cite">
          <pre wrap="">Hi Juergen,

i think your second paragraph is a very good idea. But i don't
understand the last 2 sentences. My understanding is that 
          </pre>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">the ipfix
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">requirement draft defines the ipfix protocol 
          </pre>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">requirements. So i don't
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">understand why the protocol specification must cover all 
          </pre>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">requirements.
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">E.g. when a requirementis optional why must it be covered 
          </pre>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">in the protocol
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">specification?
          </pre>
        </blockquote>
        <pre wrap="">
If the requirement doc says "the exporter MAY anonymize", then the
protocol specification MUST support anonymization in order to make
sure, that anonymization is interoperable. For example the protocol
spec MUST define how to inform a collecting process that 
        </pre>
      </blockquote>
    </blockquote>
    <pre wrap="">the data it
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">receives is anonymized. Analogously, the protocol spec 
        </pre>
      </blockquote>
    </blockquote>
    <pre wrap="">should specify
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">how to encrypt.

In both cases, the protocol specification can state that a concrete
implementation of the protocol MAY support features that serve
anonymization. Then an implementor can choose whether or 
        </pre>
      </blockquote>
    </blockquote>
    <pre wrap="">not to implement
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">this OPTIONAL feature of the protocol.
        </pre>
      </blockquote>
      <pre wrap="">You are right. The req draft contains protocol 
      </pre>
    </blockquote>
    <pre wrap="">specification requirements
    </pre>
    <blockquote type="cite">
      <pre wrap="">(which is sometimes confusing and the reason why we get 
      </pre>
    </blockquote>
    <pre wrap="">those comments).
    </pre>
    <blockquote type="cite">
      <pre wrap="">But i suggest to change the middle sentence saying that all protocol
specification requirements from the req draft must be taken 
      </pre>
    </blockquote>
    <pre wrap="">over into the
    </pre>
    <blockquote type="cite">
      <pre wrap="">protocol draft *including their significance*. Otherwise 
      </pre>
    </blockquote>
    <pre wrap="">why do we spend a
    </pre>
    <blockquote type="cite">
      <pre wrap="">long time discussing the significance of some reqs if it is 
      </pre>
    </blockquote>
    <pre wrap="">not used later
    </pre>
    <blockquote type="cite">
      <pre wrap="">in the protocol draft? Furthermore some of the reqs may be 
      </pre>
    </blockquote>
    <pre wrap="">targeting the
    </pre>
    <blockquote type="cite">
      <pre wrap="">information model or achitecture draft instead of the 
      </pre>
    </blockquote>
    <pre wrap="">protocol spec. So
    </pre>
    <blockquote type="cite">
      <pre wrap="">the sentence should not only mention the protocol spec but *also the
information model etc*. (Jeff just gave an example that 
      </pre>
    </blockquote>
    <pre wrap="">anonymization may
    </pre>
    <blockquote type="cite">
      <pre wrap="">influence the information model.)
      </pre>
    </blockquote>
    <pre wrap="">I see your point, but I would suggest a different phrasing for the
following reason:
  - I do not expect that requirement items can be mapped 
one-to-one onto
    protocol features. Some individual protocol feature will 
cover several
    requirement items at once. So here you cannot map the significance
    one-to-one, but need something like a minimum significance to be
    considered.
  - My experience from designing other protocols is that - 
compared to the
    requirements - you usually increase significance of some features
    for technical or orther reasons. We must make sure that 
the protocol
    definition process has this level of freedom.

Therefore, I suggest to extend my initially suggested paragraph

 "Many requirements in this document are not explicitly
  stated as IPFIX protocol requirements, but as requirements
  for the metering process, the exporting process, or for
  other traffic measurement components. However, every
  requirement that needs support from the IPFIX protocol
  MUST be covered by the IPFIX protocol specification
  independent of the significance of the requirement,
  which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
  Note that the protocol specification itself also assigns
  significance attributes to its features, such that a
  protocol implementation does not necessarily need to
  implement all features.<a class="moz-txt-link-rfc2396E" href="byappendingthissentenceorasimilarone:">"

by appending this sentence or a similar one:

 "</a>However, the significance assigned to a protocol feature
  MUST NOT be lower than the significance of the corresponding
  requirements."

Cheers,

    Juergen


    </pre>
    <blockquote type="cite">
      <pre wrap="">This statement must be put in the very beginning of the req draft.

The last sentence is not necessary in my opinion because 
      </pre>
    </blockquote>
    <pre wrap="">its pretty obvious
    </pre>
    <blockquote type="cite">
      <pre wrap="">that the protocol draft and the other drafts will use more (and more
detailed) reqs.

Then there is no need to change the requirements to MUST.

Cheers,

Sebastian

      </pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">I agree to say its a MUST for the protocol but not all exporters
and collectors must support it.
          </pre>
        </blockquote>
        <pre wrap="">
Agreed.

        </pre>
        <blockquote type="cite">
          <pre wrap="">But i do *not* agree at all that in general anonymization and
confidentiality is not needed in a LAN. Anonymization can 
          </pre>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">be required
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">in a LAN and even in a LAN confidentiality may be needed because i
don't want everybody who has access to my LAN to have access to my
IPFIX data.
          </pre>
        </blockquote>
        <pre wrap="">
Also agreed.

Best wishes,

   Juergen

        </pre>
        <blockquote type="cite">
          <pre wrap="">Cheers,

Sebastian

Juergen Quittek wrote:

          </pre>
          <blockquote type="cite">
            <pre wrap="">Tal, Reinaldo, and Benoit,

Do we all have the following in mind?

  Anonymization and confidentiality MUST be covered by the
  protocol specification.  But the protocol specifiction
  specification defines it as a MAY feature (anonymization)
  or SHOULD feature (confidentiality) for IPFIX protocol
  implementations.

I guess this is what the IESG reviewers were referring to.

What is probably missing in the requirements document is a
statement like the following:

  Many requirements in this document are not explicitly
  stated as IPFIX protocol requirements, but as requirements
  for the metering process, the exporting process, or for
  other traffic measurement components. However, every
  requirement that needs support from the IPFIX protocol
  MUST be covered by the IPFIX protocol specification
  independent of the significance of the requirement,
  which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
  Note that the protocol specification itself also assigns
  significance attributes to its features, such that a
  protocol implementation does not necessarily need to
  implement all features.

Any comment on this?

   Juergen


-- Tal Givoly wrote on 26 May 2003 09:42 -0700:

            </pre>
            <blockquote type="cite">
              <pre wrap="">Juergen,

I agree with Benoit - it doesn't make sense to make 
              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">confidentiality and
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">anonymization mandatory. In many deployments, there could be
physical and
other security measures that addresses these issues.

Tal

-----Original Message-----
From: majordomo listserver 
              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">[<a class="moz-txt-link-freetext" href="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</a>]On
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">Behalf
Of Benoit Claise
Sent: Monday, May 26, 2003 8:02 AM
To: Juergen Quittek
Cc: <a class="moz-txt-link-abbreviated" href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a>
Subject: Re: [ipfix] IPFIX requirements - final changes


Juergen,

              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">==============================================================
==========
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">12. Confidentiality from SHOULD to MUST

                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">==============================================================
==========
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">Problem Description:

                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">--------------------------------------------------------------
----------
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">Requirements on the ipfix implementation - the 
                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">document is long and I
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">wonder if
the working group really meant the protocol's 
                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">confidentiality and
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">anonymization
features to be so optional -  SHOULD confidentiality, MAY
anonymization.
Just for implementation.

                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">==============================================================
==========
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">Suggested solution:

                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">--------------------------------------------------------------
----------
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">  change confidentiality requirement in section 6.3.3
  from SHOULD to MUST

                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">==============================================================
==========
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">Status: solution to be agreed on

                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">==============================================================
==========
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">

I'm just wondering if a MUST is not a little bit extreme.
The draft would become:
   "Confidentiality of flow specific data transferred 
              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">from an exporting
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">   process to a collecting process MUST be ensured."
We all agree that over the Internet confidentiality is 
              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">compulsory but
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">this sentence would mean that even in a private LAN or 
              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">environment, we
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">must have confidentiality to be IPFIX compliant. And we 
              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">know that, with
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">the software based encryption, the throughput would be 
              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">lowered. Ok,
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">then
we should have an crypto engine in hardware on the 
              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">exporter to export
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">the numerous flow export packets but there is a price to it.
My point is that, as Confidentiality is not needed in 
              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">all cases, why
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">make it a MUST?

              </pre>
              <blockquote type="cite">
                <pre wrap="">


                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">==============================================================
==========
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">13. Anonymization from MAY to MUST

                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">==============================================================
==========
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">Problem Description:

                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">--------------------------------------------------------------
----------
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">Requirements on the ipfix implementation - the 
                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">document is long and I
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">wonder if
the working group really meant the protocol's 
                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">confidentiality and
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">anonymization
features to be so optional -  SHOULD confidentiality, MAY
anonymization.
Just for implementation.

                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">==============================================================
==========
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">Suggested solution:

                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">--------------------------------------------------------------
----------
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">  change anonymization requirement in section 6.7 from 
                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">MAY to MUST
    </pre>
    <pre wrap="">==============================================================
==========
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">Status: solution to be agreed on

                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">==============================================================
==========
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">

Again, I have the same type of comments. Anonymization 
              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">is not required
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">in all cases. So why make it a MUST?

Regards, Benoit.



--
Help        <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help<a class="moz-txt-link-rfc2396E" href="inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay">" in
message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"</a>unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>

              </pre>
            </blockquote>
            <pre wrap="">

--
Help        <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say 
            </pre>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">"help" in message
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">body
Unsubscribe <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>

            </pre>
          </blockquote>
          <pre wrap="">
--
Sebastian Zander                         E-mail:
<a class="moz-txt-link-abbreviated" href="mailto:zander@fokus.fraunhofer.de">zander@fokus.fraunhofer.de</a>
Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany
<a class="moz-txt-link-abbreviated" href="http://www.fokus.fraunhofer.de/usr/sebastian.zander">www.fokus.fraunhofer.de/usr/sebastian.zander</a>




          </pre>
        </blockquote>
        <pre wrap="">

        </pre>
      </blockquote>
      <pre wrap="">
--
Sebastian Zander                         E-mail: 
      </pre>
    </blockquote>
    <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:zander@fokus.fraunhofer.de">zander@fokus.fraunhofer.de</a>
    </pre>
    <blockquote type="cite">
      <pre wrap="">Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany                  
      </pre>
    </blockquote>
    <pre wrap=""><a class="moz-txt-link-abbreviated" href="http://www.fokus.fraunhofer.de/usr/sebastian.zander">www.fokus.fraunhofer.de/usr/sebastian.zander</a>
    </pre>
    <blockquote type="cite">
      <pre wrap="">


      </pre>
    </blockquote>
    <pre wrap="">

--
Help        <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help<a class="moz-txt-link-rfc2396E" href="inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay">" 
in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"</a>unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->
--
Help        <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help<a class="moz-txt-link-rfc2396E" href="inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay">" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"</a>unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>
  </pre>
</blockquote>
<br>
</body>
</html>

--------------070303020406040004050803--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun  2 07:17:22 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01442
	for <ipfix-archive@lists.ietf.org>; Mon, 2 Jun 2003 07:17:22 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Mn3B-0006Yy-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 02 Jun 2003 06:00:25 -0500
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 19Mn38-0006Yr-00
	for ipfix@net.doit.wisc.edu; Mon, 02 Jun 2003 06:00:23 -0500
Received: from cisco.com (dhcp-peg3-vl30-144-254-7-130.cisco.com [144.254.7.130])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h52B0AR15758;
	Mon, 2 Jun 2003 13:00:10 +0200 (CEST)
Message-ID: <3EDB2E38.4030509@cisco.com>
Date: Mon, 02 Jun 2003 13:00:08 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Juergen Quittek <quittek@ccrle.nec.de>
CC: Sebastian Zander <zander@fokus.fraunhofer.de>, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] IPFIX requirements - final changes
References: <3ED56280.90204@fokus.fraunhofer.de> <18754447.1054306210@[10.1.1.128]>
In-Reply-To: <18754447.1054306210@[10.1.1.128]>
Content-Type: multipart/alternative;
 boundary="------------050600030909050506000700"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.
--------------050600030909050506000700
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Juergen,

> Sebastian,
>
> -- Sebastian Zander wrote on 29 May 2003 03:29 +0200:
>
>> Juergen,
>>
>> Juergen Quittek wrote:
>>
>>> Sebastian,
>>>
>>> -- Sebastian Zander wrote on 28 May 2003 12:18 +0200:
>>>
>>>> Hi Juergen,
>>>>
>>>> i think your second paragraph is a very good idea. But i don't
>>>> understand the last 2 sentences. My understanding is that the ipfix
>>>> requirement draft defines the ipfix protocol requirements. So i don't
>>>> understand why the protocol specification must cover all requirements.
>>>> E.g. when a requirementis optional why must it be covered in the 
>>>> protocol
>>>> specification?
>>>
>>>
>>>
>>> If the requirement doc says "the exporter MAY anonymize", then the
>>> protocol specification MUST support anonymization in order to make
>>> sure, that anonymization is interoperable. For example the protocol
>>> spec MUST define how to inform a collecting process that the data it
>>> receives is anonymized. Analogously, the protocol spec should specify
>>> how to encrypt.
>>>
>>> In both cases, the protocol specification can state that a concrete
>>> implementation of the protocol MAY support features that serve
>>> anonymization. Then an implementor can choose whether or not to 
>>> implement
>>> this OPTIONAL feature of the protocol.
>>
>>
>> You are right. The req draft contains protocol specification 
>> requirements
>> (which is sometimes confusing and the reason why we get those comments).
>> But i suggest to change the middle sentence saying that all protocol
>> specification requirements from the req draft must be taken over into 
>> the
>> protocol draft *including their significance*. Otherwise why do we 
>> spend a
>> long time discussing the significance of some reqs if it is not used 
>> later
>> in the protocol draft? Furthermore some of the reqs may be targeting the
>> information model or achitecture draft instead of the protocol spec. So
>> the sentence should not only mention the protocol spec but *also the
>> information model etc*. (Jeff just gave an example that anonymization 
>> may
>> influence the information model.) 
>
I agree with Sebastian here to add *including their significance*

I see a potential with your proposed paragraph below:

    "However, the significance assigned to a protocol feature
     MUST NOT be lower than the significance of the corresponding
     requirements."

This paragraph is just comon sense; we spent sooo much time describing 
the requirements. We obviously don't want to rediscuss them
Now the possible trap is that: it MUST NOT lower, so it might be 
higher... we can start thinking...
And we start again on hot topic like adding extra reliability, changing 
MAY to SHOULD, SHOULD to MUST, etc... so rediscussing the requirements!

My vote goes to *including their significance*, as Sebastian proposed 
and removing your last paragraph.

>>
>
> I see your point, but I would suggest a different phrasing for the
> following reason:
>  - I do not expect that requirement items can be mapped one-to-one onto
>    protocol features. Some individual protocol feature will cover several
>    requirement items at once. So here you cannot map the significance
>    one-to-one, but need something like a minimum significance to be
>    considered.
>  - My experience from designing other protocols is that - compared to the
>    requirements - you usually increase significance of some features
>    for technical or orther reasons. We must make sure that the protocol
>    definition process has this level of freedom.

And if, for whatever valid reasons (like a technical one), the WG 
consensus decides to increase the significance of a specific 
requirement, then we would still be OK with our requirement draft.

Regards, Benoit.

>
>
> Therefore, I suggest to extend my initially suggested paragraph
>
> "Many requirements in this document are not explicitly
>  stated as IPFIX protocol requirements, but as requirements
>  for the metering process, the exporting process, or for
>  other traffic measurement components. However, every
>  requirement that needs support from the IPFIX protocol
>  MUST be covered by the IPFIX protocol specification
>  independent of the significance of the requirement,
>  which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
>  Note that the protocol specification itself also assigns
>  significance attributes to its features, such that a
>  protocol implementation does not necessarily need to
>  implement all features."
>
> by appending this sentence or a similar one:
>
> "However, the significance assigned to a protocol feature
>  MUST NOT be lower than the significance of the corresponding
>  requirements."
>
> Cheers,
>
>    Juergen
>
>
>> This statement must be put in the very beginning of the req draft.
>>
>> The last sentence is not necessary in my opinion because its pretty 
>> obvious
>> that the protocol draft and the other drafts will use more (and more
>> detailed) reqs.
>>
>> Then there is no need to change the requirements to MUST.
>>
>> Cheers,
>>
>> Sebastian
>>
>>>> I agree to say its a MUST for the protocol but not all exporters
>>>> and collectors must support it.
>>>
>>>
>>>
>>> Agreed.
>>>
>>>> But i do *not* agree at all that in general anonymization and
>>>> confidentiality is not needed in a LAN. Anonymization can be required
>>>> in a LAN and even in a LAN confidentiality may be needed because i
>>>> don't want everybody who has access to my LAN to have access to my
>>>> IPFIX data.
>>>
>>>
>>>
>>> Also agreed.
>>>
>>> Best wishes,
>>>
>>>    Juergen
>>>
>>>> Cheers,
>>>>
>>>> Sebastian
>>>>
>>>> Juergen Quittek wrote:
>>>>
>>>>> Tal, Reinaldo, and Benoit,
>>>>>
>>>>> Do we all have the following in mind?
>>>>>
>>>>>   Anonymization and confidentiality MUST be covered by the
>>>>>   protocol specification.  But the protocol specifiction
>>>>>   specification defines it as a MAY feature (anonymization)
>>>>>   or SHOULD feature (confidentiality) for IPFIX protocol
>>>>>   implementations.
>>>>>
>>>>> I guess this is what the IESG reviewers were referring to.
>>>>>
>>>>> What is probably missing in the requirements document is a
>>>>> statement like the following:
>>>>>
>>>>>   Many requirements in this document are not explicitly
>>>>>   stated as IPFIX protocol requirements, but as requirements
>>>>>   for the metering process, the exporting process, or for
>>>>>   other traffic measurement components. However, every
>>>>>   requirement that needs support from the IPFIX protocol
>>>>>   MUST be covered by the IPFIX protocol specification
>>>>>   independent of the significance of the requirement,
>>>>>   which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
>>>>>   Note that the protocol specification itself also assigns
>>>>>   significance attributes to its features, such that a
>>>>>   protocol implementation does not necessarily need to
>>>>>   implement all features.
>>>>>
>>>>> Any comment on this?
>>>>>
>>>>>    Juergen
>>>>>
>>>>>
>>>>> -- Tal Givoly wrote on 26 May 2003 09:42 -0700:
>>>>>
>>>>>> Juergen,
>>>>>>
>>>>>> I agree with Benoit - it doesn't make sense to make 
>>>>>> confidentiality and
>>>>>> anonymization mandatory. In many deployments, there could be
>>>>>> physical and
>>>>>> other security measures that addresses these issues.
>>>>>>
>>>>>> Tal
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On
>>>>>> Behalf
>>>>>> Of Benoit Claise
>>>>>> Sent: Monday, May 26, 2003 8:02 AM
>>>>>> To: Juergen Quittek
>>>>>> Cc: ipfix@net.doit.wisc.edu
>>>>>> Subject: Re: [ipfix] IPFIX requirements - final changes
>>>>>>
>>>>>>
>>>>>> Juergen,
>>>>>>
>>>>>>> ========================================================================
>>>>>>>
>>>>>>> 12. Confidentiality from SHOULD to MUST
>>>>>>> ========================================================================
>>>>>>>
>>>>>>> Problem Description:
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> Requirements on the ipfix implementation - the document is long 
>>>>>>> and I
>>>>>>> wonder if
>>>>>>> the working group really meant the protocol's confidentiality and
>>>>>>> anonymization
>>>>>>> features to be so optional -  SHOULD confidentiality, MAY
>>>>>>> anonymization.
>>>>>>> Just for implementation.
>>>>>>> ========================================================================
>>>>>>>
>>>>>>> Suggested solution:
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>>   change confidentiality requirement in section 6.3.3
>>>>>>>   from SHOULD to MUST
>>>>>>> ========================================================================
>>>>>>>
>>>>>>> Status: solution to be agreed on
>>>>>>> ========================================================================
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm just wondering if a MUST is not a little bit extreme.
>>>>>> The draft would become:
>>>>>>    "Confidentiality of flow specific data transferred from an 
>>>>>> exporting
>>>>>>    process to a collecting process MUST be ensured."
>>>>>> We all agree that over the Internet confidentiality is compulsory 
>>>>>> but
>>>>>> this sentence would mean that even in a private LAN or 
>>>>>> environment, we
>>>>>> must have confidentiality to be IPFIX compliant. And we know 
>>>>>> that, with
>>>>>> the software based encryption, the throughput would be lowered. Ok,
>>>>>> then
>>>>>> we should have an crypto engine in hardware on the exporter to 
>>>>>> export
>>>>>> the numerous flow export packets but there is a price to it.
>>>>>> My point is that, as Confidentiality is not needed in all cases, why
>>>>>> make it a MUST?
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ========================================================================
>>>>>>>
>>>>>>> 13. Anonymization from MAY to MUST
>>>>>>> ========================================================================
>>>>>>>
>>>>>>> Problem Description:
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> Requirements on the ipfix implementation - the document is long 
>>>>>>> and I
>>>>>>> wonder if
>>>>>>> the working group really meant the protocol's confidentiality and
>>>>>>> anonymization
>>>>>>> features to be so optional -  SHOULD confidentiality, MAY
>>>>>>> anonymization.
>>>>>>> Just for implementation.
>>>>>>> ========================================================================
>>>>>>>
>>>>>>> Suggested solution:
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>>   change anonymization requirement in section 6.7 from MAY to MUST
>>>>>>> ========================================================================
>>>>>>>
>>>>>>> Status: solution to be agreed on
>>>>>>> ========================================================================
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Again, I have the same type of comments. Anonymization is not 
>>>>>> required
>>>>>> in all cases. So why make it a MUST?
>>>>>>
>>>>>> 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/
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Sebastian Zander                         E-mail:
>>>> zander@fokus.fraunhofer.de
>>>> Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
>>>> Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
>>>> D-10589 Berlin, Germany
>>>> www.fokus.fraunhofer.de/usr/sebastian.zander
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> -- 
>> Sebastian Zander                         E-mail: 
>> zander@fokus.fraunhofer.de
>> Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
>> Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
>> D-10589 Berlin, Germany                  
>> www.fokus.fraunhofer.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/



--------------050600030909050506000700
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Juergen,<br>
<br>
<blockquote type="cite" cite="mid18754447.1054306210@%5B10.1.1.128%5D">Sebastian,<br>
  <br>
-- Sebastian Zander wrote on 29 May 2003 03:29 +0200: <br>
  <br>
  <blockquote type="cite">Juergen, <br>
    <br>
Juergen Quittek wrote: <br>
    <blockquote type="cite">Sebastian, <br>
      <br>
-- Sebastian Zander wrote on 28 May 2003 12:18 +0200: <br>
      <br>
      <blockquote type="cite">Hi Juergen, <br>
        <br>
i think your second paragraph is a very good idea. But i don't <br>
understand the last 2 sentences. My understanding is that the ipfix <br>
requirement draft defines the ipfix protocol requirements. So i don't <br>
understand why the protocol specification must cover all requirements. <br>
E.g. when a requirementis optional why must it be covered in the
protocol <br>
specification? <br>
      </blockquote>
      <br>
      <br>
If the requirement doc says "the exporter MAY anonymize", then the <br>
protocol specification MUST support anonymization in order to make <br>
sure, that anonymization is interoperable. For example the protocol <br>
spec MUST define how to inform a collecting process that the data it <br>
receives is anonymized. Analogously, the protocol spec should specify <br>
how to encrypt. <br>
      <br>
In both cases, the protocol specification can state that a concrete <br>
implementation of the protocol MAY support features that serve <br>
anonymization. Then an implementor can choose whether or not to
implement <br>
this OPTIONAL feature of the protocol. <br>
    </blockquote>
    <br>
You are right. The req draft contains protocol specification
requirements <br>
(which is sometimes confusing and the reason why we get those
comments). <br>
But i suggest to change the middle sentence saying that all protocol <br>
specification requirements from the req draft must be taken over into
the <br>
protocol draft *including their significance*. Otherwise why do we
spend a <br>
long time discussing the significance of some reqs if it is not used
later <br>
in the protocol draft? Furthermore some of the reqs may be targeting
the <br>
information model or achitecture draft instead of the protocol spec. So <br>
the sentence should not only mention the protocol spec but *also the <br>
information model etc*. (Jeff just gave an example that anonymization
may <br>
influence the information model.) </blockquote>
</blockquote>
I agree with Sebastian here to add *including their significance*<br>
<br>
I see a potential with your proposed paragraph below:<br>
<blockquote>"However, the significance assigned to a protocol feature <br>
&nbsp;MUST NOT be lower than the significance of the corresponding <br>
&nbsp;requirements." <br>
</blockquote>
This paragraph is just comon sense; we spent sooo much time describing
the requirements. We obviously don't want to rediscuss them<br>
Now the possible trap is that: it MUST NOT lower, so it might be
higher... we can start thinking...<br>
And we start again on hot topic like adding extra reliability, changing
MAY to SHOULD, SHOULD to MUST, etc... so rediscussing the requirements!<br>
<br>
My vote goes to *including their significance*, as Sebastian proposed
and removing your last paragraph.<br>
<br>
<blockquote type="cite" cite="mid18754447.1054306210@%5B10.1.1.128%5D">
  <blockquote type="cite"><br>
  </blockquote>
  <br>
I see your point, but I would suggest a different phrasing for the <br>
following reason: <br>
&nbsp;- I do not expect that requirement items can be mapped one-to-one onto <br>
&nbsp;&nbsp; protocol features. Some individual protocol feature will cover
several <br>
&nbsp;&nbsp; requirement items at once. So here you cannot map the significance <br>
&nbsp;&nbsp; one-to-one, but need something like a minimum significance to be <br>
&nbsp;&nbsp; considered. <br>
&nbsp;- My experience from designing other protocols is that - compared to
the <br>
&nbsp;&nbsp; requirements - you usually increase significance of some features <br>
&nbsp;&nbsp; for technical or orther reasons. We must make sure that the protocol <br>
&nbsp;&nbsp; definition process has this level of freedom.</blockquote>
And if, for whatever valid reasons (like a technical one), the WG
consensus decides to increase the significance of a specific
requirement, then we would still be OK with our requirement draft.<br>
<br>
Regards, Benoit.
<blockquote type="cite" cite="mid18754447.1054306210@%5B10.1.1.128%5D"><br>
  <br>
Therefore, I suggest to extend my initially suggested paragraph <br>
  <br>
"Many requirements in this document are not explicitly <br>
&nbsp;stated as IPFIX protocol requirements, but as requirements <br>
&nbsp;for the metering process, the exporting process, or for <br>
&nbsp;other traffic measurement components. However, every <br>
&nbsp;requirement that needs support from the IPFIX protocol <br>
&nbsp;MUST be covered by the IPFIX protocol specification <br>
&nbsp;independent of the significance of the requirement, <br>
&nbsp;which can be MANDATOYRY, RECOMMENDED, or OPTIONAL. <br>
&nbsp;Note that the protocol specification itself also assigns <br>
&nbsp;significance attributes to its features, such that a <br>
&nbsp;protocol implementation does not necessarily need to <br>
&nbsp;implement all features." <br>
  <br>
by appending this sentence or a similar one: <br>
  <br>
"However, the significance assigned to a protocol feature <br>
&nbsp;MUST NOT be lower than the significance of the corresponding <br>
&nbsp;requirements." <br>
  <br>
Cheers, <br>
  <br>
&nbsp;&nbsp; Juergen <br>
  <br>
  <br>
  <blockquote type="cite">This statement must be put in the very
beginning of the req draft. <br>
    <br>
The last sentence is not necessary in my opinion because its pretty
obvious <br>
that the protocol draft and the other drafts will use more (and more <br>
detailed) reqs. <br>
    <br>
Then there is no need to change the requirements to MUST. <br>
    <br>
Cheers, <br>
    <br>
Sebastian <br>
    <br>
    <blockquote type="cite">
      <blockquote type="cite">I agree to say its a MUST for the
protocol but not all exporters <br>
and collectors must support it. <br>
      </blockquote>
      <br>
      <br>
Agreed. <br>
      <br>
      <blockquote type="cite">But i do *not* agree at all that in
general anonymization and <br>
confidentiality is not needed in a LAN. Anonymization can be required <br>
in a LAN and even in a LAN confidentiality may be needed because i <br>
don't want everybody who has access to my LAN to have access to my <br>
IPFIX data. <br>
      </blockquote>
      <br>
      <br>
Also agreed. <br>
      <br>
Best wishes, <br>
      <br>
&nbsp;&nbsp; Juergen <br>
      <br>
      <blockquote type="cite">Cheers, <br>
        <br>
Sebastian <br>
        <br>
Juergen Quittek wrote: <br>
        <br>
        <blockquote type="cite">Tal, Reinaldo, and Benoit, <br>
          <br>
Do we all have the following in mind? <br>
          <br>
&nbsp; Anonymization and confidentiality MUST be covered by the <br>
&nbsp; protocol specification.&nbsp; But the protocol specifiction <br>
&nbsp; specification defines it as a MAY feature (anonymization) <br>
&nbsp; or SHOULD feature (confidentiality) for IPFIX protocol <br>
&nbsp; implementations. <br>
          <br>
I guess this is what the IESG reviewers were referring to. <br>
          <br>
What is probably missing in the requirements document is a <br>
statement like the following: <br>
          <br>
&nbsp; Many requirements in this document are not explicitly <br>
&nbsp; stated as IPFIX protocol requirements, but as requirements <br>
&nbsp; for the metering process, the exporting process, or for <br>
&nbsp; other traffic measurement components. However, every <br>
&nbsp; requirement that needs support from the IPFIX protocol <br>
&nbsp; MUST be covered by the IPFIX protocol specification <br>
&nbsp; independent of the significance of the requirement, <br>
&nbsp; which can be MANDATOYRY, RECOMMENDED, or OPTIONAL. <br>
&nbsp; Note that the protocol specification itself also assigns <br>
&nbsp; significance attributes to its features, such that a <br>
&nbsp; protocol implementation does not necessarily need to <br>
&nbsp; implement all features. <br>
          <br>
Any comment on this? <br>
          <br>
&nbsp;&nbsp; Juergen <br>
          <br>
          <br>
-- Tal Givoly wrote on 26 May 2003 09:42 -0700: <br>
          <br>
          <blockquote type="cite">Juergen, <br>
            <br>
I agree with Benoit - it doesn't make sense to make confidentiality and <br>
anonymization mandatory. In many deployments, there could be <br>
physical and <br>
other security measures that addresses these issues. <br>
            <br>
Tal <br>
            <br>
-----Original Message----- <br>
From: majordomo listserver [<a class="moz-txt-link-freetext" href="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</a>]On <br>
Behalf <br>
Of Benoit Claise <br>
Sent: Monday, May 26, 2003 8:02 AM <br>
To: Juergen Quittek <br>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a> <br>
Subject: Re: [ipfix] IPFIX requirements - final changes <br>
            <br>
            <br>
Juergen, <br>
            <br>
            <blockquote type="cite">========================================================================<br>
              <br>
12. Confidentiality from SHOULD to MUST <br>
========================================================================<br>
              <br>
Problem Description: <br>
------------------------------------------------------------------------<br>
              <br>
Requirements on the ipfix implementation - the document is long and I <br>
wonder if <br>
the working group really meant the protocol's confidentiality and <br>
anonymization <br>
features to be so optional -&nbsp; SHOULD confidentiality, MAY <br>
anonymization. <br>
Just for implementation. <br>
========================================================================<br>
              <br>
Suggested solution: <br>
------------------------------------------------------------------------<br>
              <br>
&nbsp; change confidentiality requirement in section 6.3.3 <br>
&nbsp; from SHOULD to MUST <br>
========================================================================<br>
              <br>
Status: solution to be agreed on <br>
========================================================================<br>
              <br>
            </blockquote>
            <br>
            <br>
            <br>
I'm just wondering if a MUST is not a little bit extreme. <br>
The draft would become: <br>
&nbsp;&nbsp; "Confidentiality of flow specific data transferred from an exporting <br>
&nbsp;&nbsp; process to a collecting process MUST be ensured." <br>
We all agree that over the Internet confidentiality is compulsory but <br>
this sentence would mean that even in a private LAN or environment, we <br>
must have confidentiality to be IPFIX compliant. And we know that, with <br>
the software based encryption, the throughput would be lowered. Ok, <br>
then <br>
we should have an crypto engine in hardware on the exporter to export <br>
the numerous flow export packets but there is a price to it. <br>
My point is that, as Confidentiality is not needed in all cases, why <br>
make it a MUST? <br>
            <br>
            <blockquote type="cite"> <br>
              <br>
              <br>
========================================================================<br>
              <br>
13. Anonymization from MAY to MUST <br>
========================================================================<br>
              <br>
Problem Description: <br>
------------------------------------------------------------------------<br>
              <br>
Requirements on the ipfix implementation - the document is long and I <br>
wonder if <br>
the working group really meant the protocol's confidentiality and <br>
anonymization <br>
features to be so optional -&nbsp; SHOULD confidentiality, MAY <br>
anonymization. <br>
Just for implementation. <br>
========================================================================<br>
              <br>
Suggested solution: <br>
------------------------------------------------------------------------<br>
              <br>
&nbsp; change anonymization requirement in section 6.7 from MAY to MUST <br>
========================================================================<br>
              <br>
Status: solution to be agreed on <br>
========================================================================<br>
              <br>
            </blockquote>
            <br>
            <br>
            <br>
Again, I have the same type of comments. Anonymization is not required <br>
in all cases. So why make it a MUST? <br>
            <br>
Regards, Benoit. <br>
            <br>
            <br>
            <br>
-- <br>
Help&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" in <br>
message <br>
body <br>
Unsubscribe <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say <br>
"unsubscribe ipfix" in message body <br>
Archive&nbsp;&nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a> <br>
            <br>
          </blockquote>
          <br>
          <br>
          <br>
-- <br>
Help&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" in
message <br>
body <br>
Unsubscribe <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say <br>
"unsubscribe ipfix" in message body <br>
Archive&nbsp;&nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a> <br>
          <br>
        </blockquote>
        <br>
        <br>
-- <br>
Sebastian Zander&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; E-mail: <br>
<a class="moz-txt-link-abbreviated" href="mailto:zander@fokus.fraunhofer.de">zander@fokus.fraunhofer.de</a> <br>
Fraunhofer FOKUS / METEOR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel: +49-30-3463-7287 <br>
Kaiserin-Augusta-Allee 31&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax: +49-30-3463-8287 <br>
D-10589 Berlin, Germany <br>
<a class="moz-txt-link-abbreviated" href="http://www.fokus.fraunhofer.de/usr/sebastian.zander">www.fokus.fraunhofer.de/usr/sebastian.zander</a> <br>
        <br>
        <br>
        <br>
        <br>
      </blockquote>
      <br>
      <br>
      <br>
    </blockquote>
    <br>
    <br>
-- <br>
Sebastian Zander&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; E-mail:
<a class="moz-txt-link-abbreviated" href="mailto:zander@fokus.fraunhofer.de">zander@fokus.fraunhofer.de</a> <br>
Fraunhofer FOKUS / METEOR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel: +49-30-3463-7287 <br>
Kaiserin-Augusta-Allee 31&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax: +49-30-3463-8287 <br>
D-10589 Berlin, Germany&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a class="moz-txt-link-abbreviated" href="http://www.fokus.fraunhofer.de/usr/sebastian.zander">www.fokus.fraunhofer.de/usr/sebastian.zander</a> <br>
    <br>
    <br>
    <br>
    <br>
  </blockquote>
  <br>
  <br>
  <br>
-- <br>
Help&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" in
message body <br>
Unsubscribe <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say <br>
"unsubscribe ipfix" in message body <br>
Archive&nbsp;&nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a> <br>
</blockquote>
<br>
</body>
</html>

--------------050600030909050506000700--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun  2 07:53:34 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02489
	for <ipfix-archive@lists.ietf.org>; Mon, 2 Jun 2003 07:53:33 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Mnkk-0007UF-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 02 Jun 2003 06:45:26 -0500
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Mnkj-0007U3-00
	for ipfix@net.doit.wisc.edu; Mon, 02 Jun 2003 06:45:25 -0500
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h52Bj3VI053270;
	Mon, 2 Jun 2003 13:45:03 +0200 (CEST)
Received: from [10.1.1.128] (n-quittek.office [10.1.1.128])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 75FEAA9142; Mon,  2 Jun 2003 13:33:20 +0200 (CEST)
Date: Mon, 02 Jun 2003 13:47:12 +0200
From: Juergen Quittek <quittek@ccrle.nec.de>
To: Benoit Claise <bclaise@cisco.com>
Cc: Sebastian Zander <zander@fokus.fraunhofer.de>, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] IPFIX requirements - final changes
Message-ID: <17794046.1054561632@[10.1.1.128]>
In-Reply-To: <3EDB2E38.4030509@cisco.com>
References:  <3EDB2E38.4030509@cisco.com>
X-Mailer: Mulberry/2.1.2 (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 <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Benoit,

-- Benoit Claise wrote on 02 June 2003 13:00 +0200:

> Juergen,
>
>> Sebastian,
>>
>> -- Sebastian Zander wrote on 29 May 2003 03:29 +0200:
>>
>>> Juergen,
>>>
>>> Juergen Quittek wrote:
>>>
>>>> Sebastian,
>>>>
>>>> -- Sebastian Zander wrote on 28 May 2003 12:18 +0200:
>>>>
>>>>> Hi Juergen,
>>>>>
>>>>> i think your second paragraph is a very good idea. But i don't
>>>>> understand the last 2 sentences. My understanding is that the ipfix
>>>>> requirement draft defines the ipfix protocol requirements. So i don't
>>>>> understand why the protocol specification must cover all requirements.
>>>>> E.g. when a requirementis optional why must it be covered in the
>>>>> protocol
>>>>> specification?
>>>>
>>>>
>>>>
>>>> If the requirement doc says "the exporter MAY anonymize", then the
>>>> protocol specification MUST support anonymization in order to make
>>>> sure, that anonymization is interoperable. For example the protocol
>>>> spec MUST define how to inform a collecting process that the data it
>>>> receives is anonymized. Analogously, the protocol spec should specify
>>>> how to encrypt.
>>>>
>>>> In both cases, the protocol specification can state that a concrete
>>>> implementation of the protocol MAY support features that serve
>>>> anonymization. Then an implementor can choose whether or not to
>>>> implement
>>>> this OPTIONAL feature of the protocol.
>>>
>>>
>>> You are right. The req draft contains protocol specification
>>> requirements
>>> (which is sometimes confusing and the reason why we get those comments).
>>> But i suggest to change the middle sentence saying that all protocol
>>> specification requirements from the req draft must be taken over into
>>> the
>>> protocol draft *including their significance*. Otherwise why do we
>>> spend a
>>> long time discussing the significance of some reqs if it is not used
>>> later
>>> in the protocol draft? Furthermore some of the reqs may be targeting the
>>> information model or achitecture draft instead of the protocol spec. So
>>> the sentence should not only mention the protocol spec but *also the
>>> information model etc*. (Jeff just gave an example that anonymization
>>> may
>>> influence the information model.)
>>
> I agree with Sebastian here to add *including their significance*
>
> I see a potential with your proposed paragraph below:
>
>     "However, the significance assigned to a protocol feature
>      MUST NOT be lower than the significance of the corresponding
>      requirements."
>
> This paragraph is just comon sense; we spent sooo much time describing the requirements. We obviously don't want to rediscuss them
> Now the possible trap is that: it MUST NOT lower, so it might be higher... we can start thinking...
> And we start again on hot topic like adding extra reliability, changing MAY to SHOULD, SHOULD to MUST, etc... so rediscussing the requirements!
>
> My vote goes to *including their significance*, as Sebastian proposed and removing your last paragraph.
>
>>>
>>
>> I see your point, but I would suggest a different phrasing for the
>> following reason:
>>  - I do not expect that requirement items can be mapped one-to-one onto
>>    protocol features. Some individual protocol feature will cover several
>>    requirement items at once. So here you cannot map the significance
>>    one-to-one, but need something like a minimum significance to be
>>    considered.
>>  - My experience from designing other protocols is that - compared to the
>>    requirements - you usually increase significance of some features
>>    for technical or orther reasons. We must make sure that the protocol
>>    definition process has this level of freedom.
>
> And if, for whatever valid reasons (like a technical one), the WG consensus decides to increase the significance of a specific requirement, then we would still be OK with our requirement draft.

I got yout point.  Fine with me.

Cheers,

    Juergen


> Regards, Benoit.
>
>>
>>
>> Therefore, I suggest to extend my initially suggested paragraph
>>
>> "Many requirements in this document are not explicitly
>>  stated as IPFIX protocol requirements, but as requirements
>>  for the metering process, the exporting process, or for
>>  other traffic measurement components. However, every
>>  requirement that needs support from the IPFIX protocol
>>  MUST be covered by the IPFIX protocol specification
>>  independent of the significance of the requirement,
>>  which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
>>  Note that the protocol specification itself also assigns
>>  significance attributes to its features, such that a
>>  protocol implementation does not necessarily need to
>>  implement all features."
>>
>> by appending this sentence or a similar one:
>>
>> "However, the significance assigned to a protocol feature
>>  MUST NOT be lower than the significance of the corresponding
>>  requirements."
>>
>> Cheers,
>>
>>    Juergen
>>
>>
>>> This statement must be put in the very beginning of the req draft.
>>>
>>> The last sentence is not necessary in my opinion because its pretty
>>> obvious
>>> that the protocol draft and the other drafts will use more (and more
>>> detailed) reqs.
>>>
>>> Then there is no need to change the requirements to MUST.
>>>
>>> Cheers,
>>>
>>> Sebastian
>>>
>>>>> I agree to say its a MUST for the protocol but not all exporters
>>>>> and collectors must support it.
>>>>
>>>>
>>>>
>>>> Agreed.
>>>>
>>>>> But i do *not* agree at all that in general anonymization and
>>>>> confidentiality is not needed in a LAN. Anonymization can be required
>>>>> in a LAN and even in a LAN confidentiality may be needed because i
>>>>> don't want everybody who has access to my LAN to have access to my
>>>>> IPFIX data.
>>>>
>>>>
>>>>
>>>> Also agreed.
>>>>
>>>> Best wishes,
>>>>
>>>>    Juergen
>>>>
>>>>> Cheers,
>>>>>
>>>>> Sebastian
>>>>>
>>>>> Juergen Quittek wrote:
>>>>>
>>>>>> Tal, Reinaldo, and Benoit,
>>>>>>
>>>>>> Do we all have the following in mind?
>>>>>>
>>>>>>   Anonymization and confidentiality MUST be covered by the
>>>>>>   protocol specification.  But the protocol specifiction
>>>>>>   specification defines it as a MAY feature (anonymization)
>>>>>>   or SHOULD feature (confidentiality) for IPFIX protocol
>>>>>>   implementations.
>>>>>>
>>>>>> I guess this is what the IESG reviewers were referring to.
>>>>>>
>>>>>> What is probably missing in the requirements document is a
>>>>>> statement like the following:
>>>>>>
>>>>>>   Many requirements in this document are not explicitly
>>>>>>   stated as IPFIX protocol requirements, but as requirements
>>>>>>   for the metering process, the exporting process, or for
>>>>>>   other traffic measurement components. However, every
>>>>>>   requirement that needs support from the IPFIX protocol
>>>>>>   MUST be covered by the IPFIX protocol specification
>>>>>>   independent of the significance of the requirement,
>>>>>>   which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
>>>>>>   Note that the protocol specification itself also assigns
>>>>>>   significance attributes to its features, such that a
>>>>>>   protocol implementation does not necessarily need to
>>>>>>   implement all features.
>>>>>>
>>>>>> Any comment on this?
>>>>>>
>>>>>>    Juergen
>>>>>>
>>>>>>
>>>>>> -- Tal Givoly wrote on 26 May 2003 09:42 -0700:
>>>>>>
>>>>>>> Juergen,
>>>>>>>
>>>>>>> I agree with Benoit - it doesn't make sense to make
>>>>>>> confidentiality and
>>>>>>> anonymization mandatory. In many deployments, there could be
>>>>>>> physical and
>>>>>>> other security measures that addresses these issues.
>>>>>>>
>>>>>>> Tal
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On
>>>>>>> Behalf
>>>>>>> Of Benoit Claise
>>>>>>> Sent: Monday, May 26, 2003 8:02 AM
>>>>>>> To: Juergen Quittek
>>>>>>> Cc: ipfix@net.doit.wisc.edu
>>>>>>> Subject: Re: [ipfix] IPFIX requirements - final changes
>>>>>>>
>>>>>>>
>>>>>>> Juergen,
>>>>>>>
>>>>>>>> ========================================================================
>>>>>>>>
>>>>>>>> 12. Confidentiality from SHOULD to MUST
>>>>>>>> ========================================================================
>>>>>>>>
>>>>>>>> Problem Description:
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>> Requirements on the ipfix implementation - the document is long
>>>>>>>> and I
>>>>>>>> wonder if
>>>>>>>> the working group really meant the protocol's confidentiality and
>>>>>>>> anonymization
>>>>>>>> features to be so optional -  SHOULD confidentiality, MAY
>>>>>>>> anonymization.
>>>>>>>> Just for implementation.
>>>>>>>> ========================================================================
>>>>>>>>
>>>>>>>> Suggested solution:
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>   change confidentiality requirement in section 6.3.3
>>>>>>>>   from SHOULD to MUST
>>>>>>>> ========================================================================
>>>>>>>>
>>>>>>>> Status: solution to be agreed on
>>>>>>>> ========================================================================
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I'm just wondering if a MUST is not a little bit extreme.
>>>>>>> The draft would become:
>>>>>>>    "Confidentiality of flow specific data transferred from an
>>>>>>> exporting
>>>>>>>    process to a collecting process MUST be ensured."
>>>>>>> We all agree that over the Internet confidentiality is compulsory
>>>>>>> but
>>>>>>> this sentence would mean that even in a private LAN or
>>>>>>> environment, we
>>>>>>> must have confidentiality to be IPFIX compliant. And we know
>>>>>>> that, with
>>>>>>> the software based encryption, the throughput would be lowered. Ok,
>>>>>>> then
>>>>>>> we should have an crypto engine in hardware on the exporter to
>>>>>>> export
>>>>>>> the numerous flow export packets but there is a price to it.
>>>>>>> My point is that, as Confidentiality is not needed in all cases, why
>>>>>>> make it a MUST?
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ========================================================================
>>>>>>>>
>>>>>>>> 13. Anonymization from MAY to MUST
>>>>>>>> ========================================================================
>>>>>>>>
>>>>>>>> Problem Description:
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>> Requirements on the ipfix implementation - the document is long
>>>>>>>> and I
>>>>>>>> wonder if
>>>>>>>> the working group really meant the protocol's confidentiality and
>>>>>>>> anonymization
>>>>>>>> features to be so optional -  SHOULD confidentiality, MAY
>>>>>>>> anonymization.
>>>>>>>> Just for implementation.
>>>>>>>> ========================================================================
>>>>>>>>
>>>>>>>> Suggested solution:
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>   change anonymization requirement in section 6.7 from MAY to MUST
>>>>>>>> ========================================================================
>>>>>>>>
>>>>>>>> Status: solution to be agreed on
>>>>>>>> ========================================================================
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Again, I have the same type of comments. Anonymization is not
>>>>>>> required
>>>>>>> in all cases. So why make it a MUST?
>>>>>>>
>>>>>>> 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/
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sebastian Zander                         E-mail:
>>>>> zander@fokus.fraunhofer.de
>>>>> Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
>>>>> Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
>>>>> D-10589 Berlin, Germany
>>>>> www.fokus.fraunhofer.de/usr/sebastian.zander
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Sebastian Zander                         E-mail:
>>> zander@fokus.fraunhofer.de
>>> Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
>>> Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
>>> D-10589 Berlin, Germany
>>> www.fokus.fraunhofer.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  Mon Jun  2 10:57:15 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10630
	for <ipfix-archive@lists.ietf.org>; Mon, 2 Jun 2003 10:57:14 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19MqPb-0003Av-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 02 Jun 2003 09:35:47 -0500
Received: from halt-in.cisco.com ([171.70.144.185])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19MqPZ-0003An-00
	for ipfix@net.doit.wisc.edu; Mon, 02 Jun 2003 09:35:45 -0500
Received: from cisco.com (171.71.163.13)
  by halt-in.cisco.com with ESMTP; 02 Jun 2003 07:35:55 -0800
Received: from cisco.com (sjc-vpn1-695.cisco.com [10.21.98.183])
	by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AGU38239;
	Mon, 2 Jun 2003 07:42:42 -0700 (PDT)
Message-ID: <3EDB60BE.515F00EA@cisco.com>
Date: Mon, 02 Jun 2003 07:35:42 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Juergen Quittek <quittek@ccrle.nec.de>
CC: ipfix@net.doit.wisc.edu
Subject: Re: Observation Domain [ Was Re: [ipfix] Changes to architecture doc.]
References: <3ED77965.4012EF7@cisco.com> <7519212.1054551357@[10.1.1.128]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Juergen,

  I am fine with the name "flow recording process" for the functional
  block.

  Probably we should show 2 different figures in the arch. spec.
  1. A functional block model (as drawn below in my previous e-mail)
  2. Modify the figure which is in the arch spec to show the association
     between observation point, observation domain & metering.

 Thanks
 Ganesh

Juergen Quittek wrote:

> Ganesh,
>
> Thank you for drawing the figure below. Although you say that there are
> only slight modifications, to me they are important. I fully agree to
> the new figure. Now, the observation domain really is a functional block
> not including observation points, but associated with a set of
> observation points.
>
> I still do not like the terminology, because we call a functional block
> a 'domain'. This is a minor issue, but anyway here is a suggestion:
>
> In your figure below, the box called 'observation domain' is a
> functional block. What about calling it 'flow recording process'
> or similarly. Then you could declare the 'observation domain' of
> of a flow recording process to be the set of observation points
> associated with this flow recording process.
>
> Cheers,
>
>     Juergen
> --
> Juergen Quittek        quittek@ccrle.nec.de        Tel: +49 6221 90511-15
> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
>
> -- Ganesh Sadasivan wrote on 30 May 2003 08:31 -0700:
>
> > Juergen,
> >
> >
> > Juergen Quittek wrote:
> >
> >> Ganesh
> >>
> >> -- Ganesh Sadasivan wrote on 16 May 2003 14:35 -0700:
> >>
> >> > * Section 4.3 Observation Domain
> >> > Functions of Observation domain.
> >> > " * Encoding the flow records and sending them to the export process.
> >> >   * Encoding the control information into templates and sending them to
> >> >   the export process."
> >> > The above 2 are already covered by IPFIX protocol.
> >> >
> >> > "  * Deciding which flow records/control information to export using
> >> >      rules based on time, thresholds, configuration events etc.
> >> >    * Aggregating flow records generated by one or more metering
> >> >      processes."
> >> > The above 2 are also IPFIX protocol function. So also is flow
> >> > expiration.
> >> >
> >> > Observation point is a logical block which maintains flows for a
> >>
> >> Here you mean observation domain, not observation point.
> >
> > Yes. sorry for the confusion.
> >
> >>
> >>
> >> > a set of {observation point, metering process} (in a database form)
> >> > and maintains aggregate statistics. All the other flow related
> >> > functions should be handled by IPFIX protocol and metering process.
> >> >
> >>
> >> I have a problem with the concept of an observation domain.  You say it
> >> is a 'functional block', but in the figure it includes observation points
> >> which are locations in the network and no functional blocks.  So the
> >> concept of the observation domain is not a clean one.  I see an observation
> >> domain as a useful concept for implementation design of IPFIX on a
> >> device with multiple line cards, but not useful for the general IPFIX
> >> architecture.
> >
> > The idea is to present a single identity for a group of observation points
> > to the exporter. That is why it is mentioned as a logical block which
> > encompasses a set of observation points. It does not matter whether the
> > observation points are in a single board or different board or even different
> > nodes. It is a question as to how the collector identifies a group of observation
> >
> > points.
> > Ofcourse a degenrate case is a single observation point in an observation
> > domain.
> >
> >>
> >>
> >> Also I do not see a reason, why the general architecture should define
> >> an internal function block for "sending them [flow records] from [the
> >> metering process] to the exporting process".  Why sending them, if they
> >> are co-located?  Whether or not you locate metering process and exporting
> >> process on different boards and need to send them over an internal bus
> >> is a detail of an implementation design, but IMHO should not be part
> >> of the general IPFIX architecture. And we are definitely not defining
> >> a netwrok protocol between metering process and exporting process.
> >>
> >
> > I am copying the figure down once again with slight modifications for clarity
> > and please explain how this restricts to a class of implementtations.
> >
> >    +-----------------------------+-------------------------------------+
> >    |              packet header capturing                              |
> >    |                             |               METERING PROCESS      |
> >    |                        timestamping         on an                 |
> >    |                             |               observation point     |
> >    |                             v                                     |
> >    |                      +----->+                                     |
> >    |                      |      |                                     |
> >    |                      |   sampling Si (1:1 in case of no sampling) |
> >    |                      |      |                                     |
> >    |                      | classifying Fi (NULL when No criteria)     |
> >    |                      |      |                                     |
> >    |                      +------+                                     |
> >    |                             |                                     |
> >    +-----------------------------+-------------------------------------+
> >                                  |
> >                                  v                                      .
> >                                Flows                                    .
> >                                  +--------------------------------------+...
> >                                  |
> >                                  |
> >    +-----------------------------+----------------------------------------+
> >    |                             V    OBSERVATION DOMAIN                  |
> >    |             +----------------------+         +------------------+    |
> >    |             | Flow data base       |<--------|Provide non-flow  |    |
> >    |             | (includes flows      |         | information (Eg. |    |
> >    |             | from all obs.        |         | router state)    |    |
> >    |             | points in an obs.    |         +------------------+    |
> >    |             | domain)              |                                 |
> >    |             |                      |         +------------------+    |
> >    |             |                      |<--------|Maintain aggregate|    |
> >    |             |                      |         | statistics       |    |
> >    |             +----------------------+         +------------------+    |
> >    |                                                                      |
> >    +-----------------------------+----------------------------------------+
> >                                  |
> >                             Flow Database (identified by observation domain)
> >    +-----------------------------+----------------------------------------+
> >    |                             V    IPFIX PROTOCOL                      |
> >    |             +----------------------+                                 |
> >    |             | Rules for 1. picking&|                                 |
> >    |             | sending templates    |                                 |
> >    |             | 2.picking& sending   |                                 |
> >    |             | data records 3. timi-|                                 |
> >    |             | out flows 4. Encoding|                                 |
> >    |             | template & data.     |                                 |
> >    |             |                      |                                 |
> >    |             |                      |                                 |
> >    |             |                      |                                 |
> >    |             +----------------------+                                 |
> >    |                                                                      |
> >    +----------------------------------------------------------------------+
> >
> >>
> >> The requirements do intentionally not discuss how flow records are
> >> shared between metering process and exporting process, because there
> >> are many different potential hardware and software device architectures
> >> that require different ways of communication between these processes.
> >> I do not think the IPFIX architecture should request that the there
> >> is an instance sending flow records from one process to the other,
> >> because there are several alternatives which would become excluded
> >> without need, for example shared memory (including remote memory access
> >> from the exporter to a metering card).
> >>
> >
> >  The idea is that any  function mentioned in the figure above
> > as part of an observation domain is optional, but if such a functionality exists,
> >
> > it exists in the context of an observation domain. It is like pieces in a
> > metering
> > process. Not every one would want to do sampling and classifying. But they
> > are still listed as part of metering.
> >
> >>
> >> In the requirements document we mapped requirements concerning the
> >> reports to the collecting process (for example the reporting period)
> >> to the section of requirements for the exporting process. Consequently,
> >> I would see several of the functions you listed for the observation
> >> records as part of the exporting process (for example generating templates).
> >
> > If you are refering to section 4.3 of the arch. spec, yes they specify functions
> > which
> > are not done by the observation domain. I had mentioned in my first e-mail
> > on this topic
> > "> * Section 4.3 Observation Domain
> >   > Functions of Observation domain.
> >   > " * Encoding the flow records and sending them to the export process.
> >   >   * Encoding the control information into templates and sending them to
> >   >   the export process."
> >   > The above 2 are already covered by IPFIX protocol.
> >   > "  * Deciding which flow records/control information to export using
> >   >      rules based on time, thresholds, configuration events etc.
> >   >    * Aggregating flow records generated by one or more metering
> >   >      processes."
> >   > The above 2 are also IPFIX protocol function. So also is flow
> >   > expiration. "
> > But then we have to mention that IPFIX protocol happens in the context of
> > export process.
> >
> >>
> >>
> >> For all these reasons I suggest to use the following maping of functions
> >> to metering process and exporting process.
> >>
> >> The metering process is a process triggered by packet arrival. It performs
> >> time critical wire-speed processing of packets and creating/updating of
> >> the corresponding flow records.
> >>
> >> Compared to the metering process, the export process is a rather low speed
> >> process triggered by flow timeouts and reporting interval timers (and
> >> probably by some other events). It encodes flow records into packets,
> >> generates templates and sends everything securely to the collecting process.
> >>
> >
> > Agreed.
> >
> >>
> >> Now, coming back to the point that probably was a motivation for inventing
> >> the observation domain:  If you want to split the exporting process in
> >> a portion that acts on router line cards (generating templetes and reports
> >> and a part acting on the central processor board of a router (securely
> >> exporting all reports generated on different line cards), then I suggest
> >> to split the exporting process (as defined in the requirements) into a
> >> reporting process and sending process (you might like to change terms).
> >
> > If observation domain were to do functions in 4.3 yes then there a good reason.
> > But IMO is not the function of observation domain. As far the export process
> > is concerened (which includes the IPFIX protocol), itcan be split the way
> > you mentioned above. But not mentioning this explicitly does not limit the
> > implementation on distributed systems (or does it?) .
> >
> > Thanks
> > Ganesh
> >
> >>
> >
> >>
> >>
> >> Then the chain of observation point, metering process and exporting
> >> process
> >>
> >>   O - M - E
> >>
> >> would then be replaced by the chain observation point, metering process,
> >> reporitng process and sending process
> >>
> >>   O - M - R - S
> >>
> >> Advantages:
> >>   - it is in line with the requirements
> >>   - it is consistent (not merging functions and locations)
> >>   - it still allows you to place parts of the exporting
> >>     process on line cards, while the rest remains central
> >>   - it is much in line with the PSAMP architecture
> >>     increasing synergy between both WGs
> >>
> >> Cheers,
> >>
> >>     Juergen
> >> --
> >> Juergen Quittek        quittek@ccrle.nec.de        Tel: +49 6221 90511-15
> >> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
> >> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
> >>
> >> --
> >> Help        mailto:majordomo@net.doit.wisc.edu and say "help" 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 Jun  2 12:23:47 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14044
	for <ipfix-archive@lists.ietf.org>; Mon, 2 Jun 2003 12:23:47 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19MrwO-0005DS-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 02 Jun 2003 11:13:44 -0500
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19MrwM-0005DK-00
	for ipfix@net.doit.wisc.edu; Mon, 02 Jun 2003 11:13:42 -0500
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h52GDWVI074535;
	Mon, 2 Jun 2003 18:13:32 +0200 (CEST)
Received: from [10.1.1.128] (n-quittek.office [10.1.1.128])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id C1D49A9320; Mon,  2 Jun 2003 18:01:47 +0200 (CEST)
Date: Mon, 02 Jun 2003 18:15:40 +0200
From: Juergen Quittek <quittek@ccrle.nec.de>
To: Ganesh Sadasivan <gsadasiv@cisco.com>
Cc: ipfix@net.doit.wisc.edu
Subject: Re: Observation Domain [ Was Re: [ipfix] Changes to architecture doc.]
Message-ID: <33902178.1054577740@[10.1.1.128]>
In-Reply-To: <3EDB60BE.515F00EA@cisco.com>
References:  <3EDB60BE.515F00EA@cisco.com>
X-Mailer: Mulberry/2.1.2 (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 <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Ganesh,

-- Ganesh Sadasivan wrote on 02 June 2003 07:35 -0700:

> Juergen,
>
>   I am fine with the name "flow recording process" for the functional
>   block.
>
>   Probably we should show 2 different figures in the arch. spec.
>   1. A functional block model (as drawn below in my previous e-mail)
>   2. Modify the figure which is in the arch spec to show the association
>      between observation point, observation domain & metering.

I support your suggestion.

Cheers,

    Juergen


>  Thanks
>  Ganesh
>
> Juergen Quittek wrote:
>
>> Ganesh,
>>
>> Thank you for drawing the figure below. Although you say that there are
>> only slight modifications, to me they are important. I fully agree to
>> the new figure. Now, the observation domain really is a functional block
>> not including observation points, but associated with a set of
>> observation points.
>>
>> I still do not like the terminology, because we call a functional block
>> a 'domain'. This is a minor issue, but anyway here is a suggestion:
>>
>> In your figure below, the box called 'observation domain' is a
>> functional block. What about calling it 'flow recording process'
>> or similarly. Then you could declare the 'observation domain' of
>> of a flow recording process to be the set of observation points
>> associated with this flow recording process.
>>
>> Cheers,
>>
>>     Juergen
>> --
>> Juergen Quittek        quittek@ccrle.nec.de        Tel: +49 6221 90511-15
>> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
>> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
>>
>> -- Ganesh Sadasivan wrote on 30 May 2003 08:31 -0700:
>>
>> > Juergen,
>> >
>> >
>> > Juergen Quittek wrote:
>> >
>> >> Ganesh
>> >>
>> >> -- Ganesh Sadasivan wrote on 16 May 2003 14:35 -0700:
>> >>
>> >> > * Section 4.3 Observation Domain
>> >> > Functions of Observation domain.
>> >> > " * Encoding the flow records and sending them to the export process.
>> >> >   * Encoding the control information into templates and sending them to
>> >> >   the export process."
>> >> > The above 2 are already covered by IPFIX protocol.
>> >> >
>> >> > "  * Deciding which flow records/control information to export using
>> >> >      rules based on time, thresholds, configuration events etc.
>> >> >    * Aggregating flow records generated by one or more metering
>> >> >      processes."
>> >> > The above 2 are also IPFIX protocol function. So also is flow
>> >> > expiration.
>> >> >
>> >> > Observation point is a logical block which maintains flows for a
>> >>
>> >> Here you mean observation domain, not observation point.
>> >
>> > Yes. sorry for the confusion.
>> >
>> >>
>> >>
>> >> > a set of {observation point, metering process} (in a database form)
>> >> > and maintains aggregate statistics. All the other flow related
>> >> > functions should be handled by IPFIX protocol and metering process.
>> >> >
>> >>
>> >> I have a problem with the concept of an observation domain.  You say it
>> >> is a 'functional block', but in the figure it includes observation points
>> >> which are locations in the network and no functional blocks.  So the
>> >> concept of the observation domain is not a clean one.  I see an observation
>> >> domain as a useful concept for implementation design of IPFIX on a
>> >> device with multiple line cards, but not useful for the general IPFIX
>> >> architecture.
>> >
>> > The idea is to present a single identity for a group of observation points
>> > to the exporter. That is why it is mentioned as a logical block which
>> > encompasses a set of observation points. It does not matter whether the
>> > observation points are in a single board or different board or even different
>> > nodes. It is a question as to how the collector identifies a group of observation
>> >
>> > points.
>> > Ofcourse a degenrate case is a single observation point in an observation
>> > domain.
>> >
>> >>
>> >>
>> >> Also I do not see a reason, why the general architecture should define
>> >> an internal function block for "sending them [flow records] from [the
>> >> metering process] to the exporting process".  Why sending them, if they
>> >> are co-located?  Whether or not you locate metering process and exporting
>> >> process on different boards and need to send them over an internal bus
>> >> is a detail of an implementation design, but IMHO should not be part
>> >> of the general IPFIX architecture. And we are definitely not defining
>> >> a netwrok protocol between metering process and exporting process.
>> >>
>> >
>> > I am copying the figure down once again with slight modifications for clarity
>> > and please explain how this restricts to a class of implementtations.
>> >
>> >    +-----------------------------+-------------------------------------+
>> >    |              packet header capturing                              |
>> >    |                             |               METERING PROCESS      |
>> >    |                        timestamping         on an                 |
>> >    |                             |               observation point     |
>> >    |                             v                                     |
>> >    |                      +----->+                                     |
>> >    |                      |      |                                     |
>> >    |                      |   sampling Si (1:1 in case of no sampling) |
>> >    |                      |      |                                     |
>> >    |                      | classifying Fi (NULL when No criteria)     |
>> >    |                      |      |                                     |
>> >    |                      +------+                                     |
>> >    |                             |                                     |
>> >    +-----------------------------+-------------------------------------+
>> >                                  |
>> >                                  v                                      .
>> >                                Flows                                    .
>> >                                  +--------------------------------------+...
>> >                                  |
>> >                                  |
>> >    +-----------------------------+----------------------------------------+
>> >    |                             V    OBSERVATION DOMAIN                  |
>> >    |             +----------------------+         +------------------+    |
>> >    |             | Flow data base       |<--------|Provide non-flow  |    |
>> >    |             | (includes flows      |         | information (Eg. |    |
>> >    |             | from all obs.        |         | router state)    |    |
>> >    |             | points in an obs.    |         +------------------+    |
>> >    |             | domain)              |                                 |
>> >    |             |                      |         +------------------+    |
>> >    |             |                      | <--------|Maintain aggregate|    |
>> >    |             |                      |         | statistics       |    |
>> >    |             +----------------------+         +------------------+    |
>> >    |                                                                      |
>> >    +-----------------------------+----------------------------------------+
>> >                                  |
>> >                             Flow Database (identified by observation domain)
>> >    +-----------------------------+----------------------------------------+
>> >    |                             V    IPFIX PROTOCOL                      |
>> >    |             +----------------------+                                 |
>> >    |             | Rules for 1. picking&|                                 |
>> >    |             | sending templates    |                                 |
>> >    |             | 2.picking& sending   |                                 |
>> >    |             | data records 3. timi-|                                 |
>> >    |             | out flows 4. Encoding|                                 |
>> >    |             | template & data.     |                                 |
>> >    |             |                      |                                 |
>> >    |             |                      |                                 |
>> >    |             |                      |                                 |
>> >    |             +----------------------+                                 |
>> >    |                                                                      |
>> >    +----------------------------------------------------------------------+
>> >
>> >>
>> >> The requirements do intentionally not discuss how flow records are
>> >> shared between metering process and exporting process, because there
>> >> are many different potential hardware and software device architectures
>> >> that require different ways of communication between these processes.
>> >> I do not think the IPFIX architecture should request that the there
>> >> is an instance sending flow records from one process to the other,
>> >> because there are several alternatives which would become excluded
>> >> without need, for example shared memory (including remote memory access
>> >> from the exporter to a metering card).
>> >>
>> >
>> >  The idea is that any  function mentioned in the figure above
>> > as part of an observation domain is optional, but if such a functionality exists,
>> >
>> > it exists in the context of an observation domain. It is like pieces in a
>> > metering
>> > process. Not every one would want to do sampling and classifying. But they
>> > are still listed as part of metering.
>> >
>> >>
>> >> In the requirements document we mapped requirements concerning the
>> >> reports to the collecting process (for example the reporting period)
>> >> to the section of requirements for the exporting process. Consequently,
>> >> I would see several of the functions you listed for the observation
>> >> records as part of the exporting process (for example generating templates).
>> >
>> > If you are refering to section 4.3 of the arch. spec, yes they specify functions
>> > which
>> > are not done by the observation domain. I had mentioned in my first e-mail
>> > on this topic
>> > "> * Section 4.3 Observation Domain
>> >   > Functions of Observation domain.
>> >   > " * Encoding the flow records and sending them to the export process.
>> >   >   * Encoding the control information into templates and sending them to
>> >   >   the export process."
>> >   > The above 2 are already covered by IPFIX protocol.
>> >   > "  * Deciding which flow records/control information to export using
>> >   >      rules based on time, thresholds, configuration events etc.
>> >   >    * Aggregating flow records generated by one or more metering
>> >   >      processes."
>> >   > The above 2 are also IPFIX protocol function. So also is flow
>> >   > expiration. "
>> > But then we have to mention that IPFIX protocol happens in the context of
>> > export process.
>> >
>> >>
>> >>
>> >> For all these reasons I suggest to use the following maping of functions
>> >> to metering process and exporting process.
>> >>
>> >> The metering process is a process triggered by packet arrival. It performs
>> >> time critical wire-speed processing of packets and creating/updating of
>> >> the corresponding flow records.
>> >>
>> >> Compared to the metering process, the export process is a rather low speed
>> >> process triggered by flow timeouts and reporting interval timers (and
>> >> probably by some other events). It encodes flow records into packets,
>> >> generates templates and sends everything securely to the collecting process.
>> >>
>> >
>> > Agreed.
>> >
>> >>
>> >> Now, coming back to the point that probably was a motivation for inventing
>> >> the observation domain:  If you want to split the exporting process in
>> >> a portion that acts on router line cards (generating templetes and reports
>> >> and a part acting on the central processor board of a router (securely
>> >> exporting all reports generated on different line cards), then I suggest
>> >> to split the exporting process (as defined in the requirements) into a
>> >> reporting process and sending process (you might like to change terms).
>> >
>> > If observation domain were to do functions in 4.3 yes then there a good reason.
>> > But IMO is not the function of observation domain. As far the export process
>> > is concerened (which includes the IPFIX protocol), itcan be split the way
>> > you mentioned above. But not mentioning this explicitly does not limit the
>> > implementation on distributed systems (or does it?) .
>> >
>> > Thanks
>> > Ganesh
>> >
>> >>
>> >
>> >>
>> >>
>> >> Then the chain of observation point, metering process and exporting
>> >> process
>> >>
>> >>   O - M - E
>> >>
>> >> would then be replaced by the chain observation point, metering process,
>> >> reporitng process and sending process
>> >>
>> >>   O - M - R - S
>> >>
>> >> Advantages:
>> >>   - it is in line with the requirements
>> >>   - it is consistent (not merging functions and locations)
>> >>   - it still allows you to place parts of the exporting
>> >>     process on line cards, while the rest remains central
>> >>   - it is much in line with the PSAMP architecture
>> >>     increasing synergy between both WGs
>> >>
>> >> Cheers,
>> >>
>> >>     Juergen
>> >> --
>> >> Juergen Quittek        quittek@ccrle.nec.de        Tel: +49 6221 90511-15
>> >> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
>> >> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
>> >>
>> >> --
>> >> Help        mailto:majordomo@net.doit.wisc.edu and say "help" 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 Jun  2 14:58:56 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18998
	for <ipfix-archive@lists.ietf.org>; Mon, 2 Jun 2003 14:58:55 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19MuE0-0000Mg-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 02 Jun 2003 13:40:04 -0500
Received: from palrel12.hp.com ([156.153.255.237])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19MuDy-0000M5-00
	for ipfix@net.doit.wisc.edu; Mon, 02 Jun 2003 13:40:02 -0500
Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65])
	by palrel12.hp.com (Postfix) with ESMTP
	id 74DB41C01613; Mon,  2 Jun 2003 11:39:59 -0700 (PDT)
Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63])
	by xparelay2.ptp.hp.com (Postfix) with ESMTP
	id 5141E1C00A77; Mon,  2 Jun 2003 11:39:59 -0700 (PDT)
Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <L59KZZXQ>; Mon, 2 Jun 2003 11:39:59 -0700
Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50295FFF7@xsun01.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Benoit Claise'" <bclaise@cisco.com>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
Cc: "'Juergen Quittek'" <quittek@ccrle.nec.de>,
        "'Sebastian Zander'" <zander@fokus.fraunhofer.de>,
        "'ipfix@net.doit.wisc.edu'" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] IPFIX requirements - final changes
Date: Mon, 2 Jun 2003 11:39:54 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C32936.5C47AD80"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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_01C32936.5C47AD80
Content-Type: text/plain;
	charset="iso-8859-1"

Benoit,
 
  Makes sense to me.  Since we are decomposing the problem into
architecture, info model and protocol, it may be that any of these address
this.
 
-- Jeff

-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Monday, June 02, 2003 3:44 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'Juergen Quittek'; Sebastian Zander; ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] IPFIX requirements - final changes


Jeff,


  Your phrasing sounds good:



 "Many requirements in this document are not explicitly

  stated as IPFIX protocol requirements, but as requirements

  for the metering process, the exporting process, or for

  other traffic measurement components. However, every

  requirement that needs support from the IPFIX protocol

  MUST be covered by the IPFIX protocol specification

  independent of the significance of the requirement,

  which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.

  Note that the protocol specification itself also assigns

  significance attributes to its features, such that a

  protocol implementation does not necessarily need to

  implement all features."



  One change I would suggest is to recognize that the specification

contains both a protocol and an (extendable) information model.

E.g. anonymization can be addressed w/o any change to the

protocol.



  So I'd rather see one of the sentences modified as:



    However, every requirement that needs support from the 

  IPFIX protocol or information model MUST be covered by the 

  IPFIX protocol or information model specification

  independent of the significance of the requirement

You have a good point.
Now, I'm thinking loud here.
Aren't they any requirements that influence the architecture draft?
So should we have this sentence more generic? And as a consequence include a
pointer to the architecture draft?
I think this is worth mentioning.

So this paragraph would become (at least regarding the meaning):

    However, every requirement that needs support from one or multiple
drafts (IPFIX architecture, I PFIX protocol, information model) MUST be
covered by the respective specification

    independent of the significance of the requirement
Regards, Benoit.






Regards,



  Jeff Meyer



  

-----Original Message-----

From: Juergen Quittek [ mailto:quittek@ccrle.nec.de
<mailto:quittek@ccrle.nec.de> ]

Sent: Friday, May 30, 2003 5:50 AM

To: Sebastian Zander

Cc:  ipfix@net.doit.wisc.edu <mailto:ipfix@net.doit.wisc.edu> 

Subject: Re: [ipfix] IPFIX requirements - final changes





Sebastian,



-- Sebastian Zander wrote on 29 May 2003 03:29 +0200:



    

Juergen,



Juergen Quittek wrote:

      

Sebastian,



-- Sebastian Zander wrote on 28 May 2003 12:18 +0200:



        

Hi Juergen,



i think your second paragraph is a very good idea. But i don't

understand the last 2 sentences. My understanding is that 

          

the ipfix

    

requirement draft defines the ipfix protocol 

          

requirements. So i don't

    

understand why the protocol specification must cover all 

          

requirements.

    

E.g. when a requirementis optional why must it be covered 

          

in the protocol

    

specification?

          

If the requirement doc says "the exporter MAY anonymize", then the

protocol specification MUST support anonymization in order to make

sure, that anonymization is interoperable. For example the protocol

spec MUST define how to inform a collecting process that 

        

the data it

    

receives is anonymized. Analogously, the protocol spec 

        

should specify

    

how to encrypt.



In both cases, the protocol specification can state that a concrete

implementation of the protocol MAY support features that serve

anonymization. Then an implementor can choose whether or 

        

not to implement

    

this OPTIONAL feature of the protocol.

        

You are right. The req draft contains protocol 

      

specification requirements

    

(which is sometimes confusing and the reason why we get 

      

those comments).

    

But i suggest to change the middle sentence saying that all protocol

specification requirements from the req draft must be taken 

      

over into the

    

protocol draft *including their significance*. Otherwise 

      

why do we spend a

    

long time discussing the significance of some reqs if it is 

      

not used later

    

in the protocol draft? Furthermore some of the reqs may be 

      

targeting the

    

information model or achitecture draft instead of the 

      

protocol spec. So

    

the sentence should not only mention the protocol spec but *also the

information model etc*. (Jeff just gave an example that 

      

anonymization may

    

influence the information model.)

      

I see your point, but I would suggest a different phrasing for the

following reason:

  - I do not expect that requirement items can be mapped 

one-to-one onto

    protocol features. Some individual protocol feature will 

cover several

    requirement items at once. So here you cannot map the significance

    one-to-one, but need something like a minimum significance to be

    considered.

  - My experience from designing other protocols is that - 

compared to the

    requirements - you usually increase significance of some features

    for technical or orther reasons. We must make sure that 

the protocol

    definition process has this level of freedom.



Therefore, I suggest to extend my initially suggested paragraph



 "Many requirements in this document are not explicitly

  stated as IPFIX protocol requirements, but as requirements

  for the metering process, the exporting process, or for

  other traffic measurement components. However, every

  requirement that needs support from the IPFIX protocol

  MUST be covered by the IPFIX protocol specification

  independent of the significance of the requirement,

  which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.

  Note that the protocol specification itself also assigns

  significance attributes to its features, such that a

  protocol implementation does not necessarily need to

  implement all features. " <byappendingthissentenceorasimilarone:> 



by appending this sentence or a similar one:



 "However, the significance assigned to a protocol feature

  MUST NOT be lower than the significance of the corresponding

  requirements."



Cheers,



    Juergen





    

This statement must be put in the very beginning of the req draft.



The last sentence is not necessary in my opinion because 

      

its pretty obvious

    

that the protocol draft and the other drafts will use more (and more

detailed) reqs.



Then there is no need to change the requirements to MUST.



Cheers,



Sebastian



      

I agree to say its a MUST for the protocol but not all exporters

and collectors must support it.

          

Agreed.



        

But i do *not* agree at all that in general anonymization and

confidentiality is not needed in a LAN. Anonymization can 

          

be required

    

in a LAN and even in a LAN confidentiality may be needed because i

don't want everybody who has access to my LAN to have access to my

IPFIX data.

          

Also agreed.



Best wishes,



   Juergen



        

Cheers,



Sebastian



Juergen Quittek wrote:



          

Tal, Reinaldo, and Benoit,



Do we all have the following in mind?



  Anonymization and confidentiality MUST be covered by the

  protocol specification.  But the protocol specifiction

  specification defines it as a MAY feature (anonymization)

  or SHOULD feature (confidentiality) for IPFIX protocol

  implementations.



I guess this is what the IESG reviewers were referring to.



What is probably missing in the requirements document is a

statement like the following:



  Many requirements in this document are not explicitly

  stated as IPFIX protocol requirements, but as requirements

  for the metering process, the exporting process, or for

  other traffic measurement components. However, every

  requirement that needs support from the IPFIX protocol

  MUST be covered by the IPFIX protocol specification

  independent of the significance of the requirement,

  which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.

  Note that the protocol specification itself also assigns

  significance attributes to its features, such that a

  protocol implementation does not necessarily need to

  implement all features.



Any comment on this?



   Juergen





-- Tal Givoly wrote on 26 May 2003 09:42 -0700:



            

Juergen,



I agree with Benoit - it doesn't make sense to make 

              

confidentiality and

    

anonymization mandatory. In many deployments, there could be

physical and

other security measures that addresses these issues.



Tal



-----Original Message-----

From: majordomo listserver 

              

[ mailto:majordomo@mil.doit.wisc.edu <mailto:majordomo@mil.doit.wisc.edu>
]On

    

Behalf

Of Benoit Claise

Sent: Monday, May 26, 2003 8:02 AM

To: Juergen Quittek

Cc:  ipfix@net.doit.wisc.edu <mailto:ipfix@net.doit.wisc.edu> 

Subject: Re: [ipfix] IPFIX requirements - final changes





Juergen,



              

==============================================================

==========

    

12. Confidentiality from SHOULD to MUST



                

==============================================================

==========

    

Problem Description:



                

--------------------------------------------------------------

----------

    

Requirements on the ipfix implementation - the 

                

document is long and I

    

wonder if

the working group really meant the protocol's 

                

confidentiality and

    

anonymization

features to be so optional -  SHOULD confidentiality, MAY

anonymization.

Just for implementation.



                

==============================================================

==========

    

Suggested solution:



                

--------------------------------------------------------------

----------

    

  change confidentiality requirement in section 6.3.3

  from SHOULD to MUST



                

==============================================================

==========

    

Status: solution to be agreed on



                

==============================================================

==========

    



I'm just wondering if a MUST is not a little bit extreme.

The draft would become:

   "Confidentiality of flow specific data transferred 

              

from an exporting

    

   process to a collecting process MUST be ensured."

We all agree that over the Internet confidentiality is 

              

compulsory but

    

this sentence would mean that even in a private LAN or 

              

environment, we

    

must have confidentiality to be IPFIX compliant. And we 

              

know that, with

    

the software based encryption, the throughput would be 

              

lowered. Ok,

    

then

we should have an crypto engine in hardware on the 

              

exporter to export

    

the numerous flow export packets but there is a price to it.

My point is that, as Confidentiality is not needed in 

              

all cases, why

    

make it a MUST?



              





                

==============================================================

==========

    

13. Anonymization from MAY to MUST



                

==============================================================

==========

    

Problem Description:



                

--------------------------------------------------------------

----------

    

Requirements on the ipfix implementation - the 

                

document is long and I

    

wonder if

the working group really meant the protocol's 

                

confidentiality and

    

anonymization

features to be so optional -  SHOULD confidentiality, MAY

anonymization.

Just for implementation.



                

==============================================================

==========

    

Suggested solution:



                

--------------------------------------------------------------

----------

    

  change anonymization requirement in section 6.7 from 

                

MAY to MUST

    
==============================================================

==========

    

Status: solution to be agreed on



                

==============================================================

==========

    



Again, I have the same type of comments. Anonymization 

              

is not required

    

in all cases. So why make it a MUST?



Regards, Benoit.







--

Help         mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say "help " in
<inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay> 

message

body

Unsubscribe mailto:majordomo@net.doit.wisc.edu and say

"unsubscribe ipfix" in message body

Archive      http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/> 



              



--

Help         mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say 

            

"help" in message

    

body

Unsubscribe  mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say

"unsubscribe ipfix" in message body

Archive      http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/> 



            

--

Sebastian Zander                         E-mail:

zander@fokus.fraunhofer.de <mailto:zander@fokus.fraunhofer.de> 

Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287

Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287

D-10589 Berlin, Germany

www.fokus.fraunhofer.de/usr/sebastian.zander
<http://www.fokus.fraunhofer.de/usr/sebastian.zander> 









          



        

--

Sebastian Zander                         E-mail: 

      

zander@fokus.fraunhofer.de <mailto:zander@fokus.fraunhofer.de> 

    

Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287

Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287

D-10589 Berlin, Germany                  

      

www.fokus.fraunhofer.de/usr/sebastian.zander
<http://www.fokus.fraunhofer.de/usr/sebastian.zander> 

    





      



--

Help         mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say "help "
<inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay> 

in message body

Unsubscribe mailto:majordomo@net.doit.wisc.edu and say

"unsubscribe ipfix" in message body

Archive      http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/> 



    



--

Help         mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say "help " in message body
<inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay> 

Unsubscribe mailto:majordomo@net.doit.wisc.edu and say

"unsubscribe ipfix" in message body

Archive      http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/> 

  



------_=_NextPart_001_01C32936.5C47AD80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE></TITLE>

<META content=3D"MSHTML 5.50.4915.500" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D078215416-02062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Benoit,</FONT></SPAN></DIV>
<DIV><SPAN class=3D078215416-02062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D078215416-02062003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
Makes sense to me.&nbsp;&nbsp;Since we are decomposing the problem into =

architecture, info model and protocol, it may be that any of these =
address=20
this.</FONT></SPAN></DIV>
<DIV><SPAN class=3D078215416-02062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D078215416-02062003><FONT face=3DArial =
color=3D#0000ff size=3D2>--=20
Jeff</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Benoit Claise=20
  [mailto:bclaise@cisco.com]<BR><B>Sent:</B> Monday, June 02, 2003 3:44 =

  AM<BR><B>To:</B> MEYER,JEFFREY D (HP-Cupertino,ex1)<BR><B>Cc:</B> =
'Juergen=20
  Quittek'; Sebastian Zander; =
ipfix@net.doit.wisc.edu<BR><B>Subject:</B> Re:=20
  [ipfix] IPFIX requirements - final =
changes<BR><BR></FONT></DIV>Jeff,<BR>
  <BLOCKQUOTE=20
  =
cite=3D"mid1D3D2C371FCBD947A7897FABBD3533A50295FFEB@xsun01.ptp.hp.com"=20
  type=3D"cite"><PRE wrap=3D"">  Your phrasing sounds good:

 "Many requirements in this document are not explicitly
  stated as IPFIX protocol requirements, but as requirements
  for the metering process, the exporting process, or for
  other traffic measurement components. However, every
  requirement that needs support from the IPFIX protocol
  MUST be covered by the IPFIX protocol specification
  independent of the significance of the requirement,
  which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
  Note that the protocol specification itself also assigns
  significance attributes to its features, such that a
  protocol implementation does not necessarily need to
  implement all features."

  One change I would suggest is to recognize that the specification
contains both a protocol and an (extendable) information model.
E.g. anonymization can be addressed w/o any change to the
protocol.

  So I'd rather see one of the sentences modified as:

    However, every requirement that needs support from the=20
  IPFIX protocol or information model MUST be covered by the=20
  IPFIX protocol or information model specification
  independent of the significance of the =
requirement</PRE></BLOCKQUOTE>You=20
  have a good point.<BR>Now, I'm thinking loud here.<BR>Aren't they any =

  requirements that influence the architecture draft?<BR>So should we =
have this=20
  sentence more generic? And as a consequence include a pointer to the=20
  architecture draft?<BR>I think this is worth mentioning.<BR><BR>So =
this=20
  paragraph would become (at least regarding the meaning):<BR><PRE =
wrap=3D"">    However, every requirement that needs support from one or =
multiple drafts (IPFIX architecture, I PFIX protocol, information =
model) MUST be covered by the<SPAN class=3Dmoz-txt-citetags></SPAN> =
respective specification
<SPAN class=3Dmoz-txt-citetags> </SPAN>   independent of the =
significance of the requirement
</PRE>Regards, Benoit.<BR><BR><BR>
  <BLOCKQUOTE=20
  =
cite=3D"mid1D3D2C371FCBD947A7897FABBD3533A50295FFEB@xsun01.ptp.hp.com"=20
  type=3D"cite"><PRE wrap=3D"">
Regards,

  Jeff Meyer

  </PRE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">-----Original Message-----
From: Juergen Quittek [<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:quittek@ccrle.nec.de">mailto:quittek@ccrle.nec.de</A>]
Sent: Friday, May 30, 2003 5:50 AM
To: Sebastian Zander
Cc: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</A>
Subject: Re: [ipfix] IPFIX requirements - final changes


Sebastian,

-- Sebastian Zander wrote on 29 May 2003 03:29 +0200:

    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Juergen,

Juergen Quittek wrote:
      </PRE>
        <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Sebastian,

-- Sebastian Zander wrote on 28 May 2003 12:18 +0200:

        </PRE>
          <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi Juergen,

i think your second paragraph is a very good idea. But i don't
understand the last 2 sentences. My understanding is that=20
          </PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><PRE =
wrap=3D"">the ipfix
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">requirement draft =
defines the ipfix protocol=20
          </PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><PRE =
wrap=3D"">requirements. So i don't
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">understand why the =
protocol specification must cover all=20
          </PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><PRE =
wrap=3D"">requirements.
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">E.g. when a =
requirementis optional why must it be covered=20
          </PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><PRE =
wrap=3D"">in the protocol
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">specification?
          </PRE></BLOCKQUOTE><PRE wrap=3D"">If the requirement doc says =
"the exporter MAY anonymize", then the
protocol specification MUST support anonymization in order to make
sure, that anonymization is interoperable. For example the protocol
spec MUST define how to inform a collecting process that=20
        </PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D"">the data it
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">receives is =
anonymized. Analogously, the protocol spec=20
        </PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D"">should specify
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">how to encrypt.

In both cases, the protocol specification can state that a concrete
implementation of the protocol MAY support features that serve
anonymization. Then an implementor can choose whether or=20
        </PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D"">not to implement
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">this OPTIONAL feature =
of the protocol.
        </PRE></BLOCKQUOTE><PRE wrap=3D"">You are right. The req draft =
contains protocol=20
      </PRE></BLOCKQUOTE><PRE wrap=3D"">specification requirements
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">(which is sometimes =
confusing and the reason why we get=20
      </PRE></BLOCKQUOTE><PRE wrap=3D"">those comments).
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">But i suggest to change =
the middle sentence saying that all protocol
specification requirements from the req draft must be taken=20
      </PRE></BLOCKQUOTE><PRE wrap=3D"">over into the
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">protocol draft =
*including their significance*. Otherwise=20
      </PRE></BLOCKQUOTE><PRE wrap=3D"">why do we spend a
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">long time discussing the =
significance of some reqs if it is=20
      </PRE></BLOCKQUOTE><PRE wrap=3D"">not used later
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">in the protocol draft? =
Furthermore some of the reqs may be=20
      </PRE></BLOCKQUOTE><PRE wrap=3D"">targeting the
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">information model or =
achitecture draft instead of the=20
      </PRE></BLOCKQUOTE><PRE wrap=3D"">protocol spec. So
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">the sentence should not =
only mention the protocol spec but *also the
information model etc*. (Jeff just gave an example that=20
      </PRE></BLOCKQUOTE><PRE wrap=3D"">anonymization may
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">influence the =
information model.)
      </PRE></BLOCKQUOTE><PRE wrap=3D"">I see your point, but I would =
suggest a different phrasing for the
following reason:
  - I do not expect that requirement items can be mapped=20
one-to-one onto
    protocol features. Some individual protocol feature will=20
cover several
    requirement items at once. So here you cannot map the significance
    one-to-one, but need something like a minimum significance to be
    considered.
  - My experience from designing other protocols is that -=20
compared to the
    requirements - you usually increase significance of some features
    for technical or orther reasons. We must make sure that=20
the protocol
    definition process has this level of freedom.

Therefore, I suggest to extend my initially suggested paragraph

 "Many requirements in this document are not explicitly
  stated as IPFIX protocol requirements, but as requirements
  for the metering process, the exporting process, or for
  other traffic measurement components. However, every
  requirement that needs support from the IPFIX protocol
  MUST be covered by the IPFIX protocol specification
  independent of the significance of the requirement,
  which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
  Note that the protocol specification itself also assigns
  significance attributes to its features, such that a
  protocol implementation does not necessarily need to
  implement all features.<A class=3Dmoz-txt-link-rfc2396E =
href=3D"byappendingthissentenceorasimilarone:">"

by appending this sentence or a similar one:

 "</A>However, the significance assigned to a protocol feature
  MUST NOT be lower than the significance of the corresponding
  requirements."

Cheers,

    Juergen


    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">This statement must be =
put in the very beginning of the req draft.

The last sentence is not necessary in my opinion because=20
      </PRE></BLOCKQUOTE><PRE wrap=3D"">its pretty obvious
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">that the protocol draft =
and the other drafts will use more (and more
detailed) reqs.

Then there is no need to change the requirements to MUST.

Cheers,

Sebastian

      </PRE>
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">I agree to say its a =
MUST for the protocol but not all exporters
and collectors must support it.
          </PRE></BLOCKQUOTE><PRE wrap=3D"">Agreed.

        </PRE>
          <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">But i do *not* agree =
at all that in general anonymization and
confidentiality is not needed in a LAN. Anonymization can=20
          </PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><PRE =
wrap=3D"">be required
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">in a LAN and even in =
a LAN confidentiality may be needed because i
don't want everybody who has access to my LAN to have access to my
IPFIX data.
          </PRE></BLOCKQUOTE><PRE wrap=3D"">Also agreed.

Best wishes,

   Juergen

        </PRE>
          <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Cheers,

Sebastian

Juergen Quittek wrote:

          </PRE>
            <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Tal, Reinaldo, and =
Benoit,

Do we all have the following in mind?

  Anonymization and confidentiality MUST be covered by the
  protocol specification.  But the protocol specifiction
  specification defines it as a MAY feature (anonymization)
  or SHOULD feature (confidentiality) for IPFIX protocol
  implementations.

I guess this is what the IESG reviewers were referring to.

What is probably missing in the requirements document is a
statement like the following:

  Many requirements in this document are not explicitly
  stated as IPFIX protocol requirements, but as requirements
  for the metering process, the exporting process, or for
  other traffic measurement components. However, every
  requirement that needs support from the IPFIX protocol
  MUST be covered by the IPFIX protocol specification
  independent of the significance of the requirement,
  which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
  Note that the protocol specification itself also assigns
  significance attributes to its features, such that a
  protocol implementation does not necessarily need to
  implement all features.

Any comment on this?

   Juergen


-- Tal Givoly wrote on 26 May 2003 09:42 -0700:

            </PRE>
              <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Juergen,

I agree with Benoit - it doesn't make sense to make=20
              =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
PRE wrap=3D"">confidentiality and
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">anonymization =
mandatory. In many deployments, there could be
physical and
other security measures that addresses these issues.

Tal

-----Original Message-----
From: majordomo listserver=20
              =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
PRE wrap=3D"">[<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wi=
sc.edu</A>]On
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Behalf
Of Benoit Claise
Sent: Monday, May 26, 2003 8:02 AM
To: Juergen Quittek
Cc: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</A>
Subject: Re: [ipfix] IPFIX requirements - final changes


Juergen,

              =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
PRE =
wrap=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=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
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite">
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">12. =
Confidentiality from SHOULD to MUST

                =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE><PRE =
wrap=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=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
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite">
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Problem =
Description:

                =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE><PRE =
wrap=3D"">--------------------------------------------------------------=

----------
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite">
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Requirements =
on the ipfix implementation - the=20
                =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE><PRE wrap=3D"">document is long and I
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite">
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">wonder if
the working group really meant the protocol's=20
                </PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOT=
E></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D"">confidentiality and
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite">
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">anonymization
features to be so optional -  SHOULD confidentiality, MAY
anonymization.
Just for implementation.

                =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE><PRE =
wrap=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=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
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite">
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Suggested =
solution:

                =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE><PRE =
wrap=3D"">--------------------------------------------------------------=

----------
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite">
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">  change =
confidentiality requirement in section 6.3.3
  from SHOULD to MUST

                =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE><PRE =
wrap=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=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
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite">
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Status: =
solution to be agreed on

                =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE><PRE =
wrap=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=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
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">
I'm just wondering if a MUST is not a little bit extreme.
The draft would become:
   "Confidentiality of flow specific data transferred=20
              =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
PRE wrap=3D"">from an exporting
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">   process to a =
collecting process MUST be ensured."
We all agree that over the Internet confidentiality is=20
              =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
PRE wrap=3D"">compulsory but
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">this sentence =
would mean that even in a private LAN or=20
              =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
PRE wrap=3D"">environment, we
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">must have =
confidentiality to be IPFIX compliant. And we=20
              =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
PRE wrap=3D"">know that, with
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">the software =
based encryption, the throughput would be=20
              =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
PRE wrap=3D"">lowered. Ok,
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">then
we should have an crypto engine in hardware on the=20
              =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
PRE wrap=3D"">exporter to export
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">the numerous =
flow export packets but there is a price to it.
My point is that, as Confidentiality is not needed in=20
              =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
PRE wrap=3D"">all cases, why
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">make it a MUST?

              </PRE>
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">

                =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE><PRE =
wrap=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=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
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite">
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">13. =
Anonymization from MAY to MUST

                =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE><PRE =
wrap=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=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
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite">
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Problem =
Description:

                =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE><PRE =
wrap=3D"">--------------------------------------------------------------=

----------
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite">
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Requirements =
on the ipfix implementation - the=20
                =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE><PRE wrap=3D"">document is long and I
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite">
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">wonder if
the working group really meant the protocol's=20
                =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE><PRE wrap=3D"">confidentiality and
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite">
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">anonymization
features to be so optional -  SHOULD confidentiality, MAY
anonymization.
Just for implementation.

                =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE><PRE =
wrap=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=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
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite">
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Suggested =
solution:

                =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE><PRE =
wrap=3D"">--------------------------------------------------------------=

----------
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite">
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">  change =
anonymization requirement in section 6.7 from=20
                =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE><PRE wrap=3D"">MAY to MUST
    </PRE><PRE =
wrap=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=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
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite">
                <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Status: =
solution to be agreed on

                =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
/BLOCKQUOTE><PRE =
wrap=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=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
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">
Again, I have the same type of comments. Anonymization=20
              =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><=
PRE wrap=3D"">is not required
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite">
              <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">in all cases. So =
why make it a MUST?

Regards, Benoit.



--
Help        <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wi=
sc.edu</A> and say "help<A class=3Dmoz-txt-link-rfc2396E =
href=3D"inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay=
">" in
message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"</A>unsubscribe ipfix" in message body
Archive     <A class=3Dmoz-txt-link-freetext =
href=3D"http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/=
archive/</A>

              </PRE></BLOCKQUOTE><PRE wrap=3D"">
--
Help        <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wi=
sc.edu</A> and say=20
            =
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><PRE =
wrap=3D"">"help" in message
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite">
          <BLOCKQUOTE type=3D"cite">
            <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">body
Unsubscribe <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wi=
sc.edu</A> and say
"unsubscribe ipfix" in message body
Archive     <A class=3Dmoz-txt-link-freetext =
href=3D"http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/=
archive/</A>

            </PRE></BLOCKQUOTE><PRE wrap=3D"">--
Sebastian Zander                         E-mail:
<A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:zander@fokus.fraunhofer.de">zander@fokus.fraunhofer.de</A=
>
Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany
<A class=3Dmoz-txt-link-abbreviated =
href=3D"http://www.fokus.fraunhofer.de/usr/sebastian.zander">www.fokus.f=
raunhofer.de/usr/sebastian.zander</A>




          </PRE></BLOCKQUOTE><PRE wrap=3D"">
        </PRE></BLOCKQUOTE><PRE wrap=3D"">--
Sebastian Zander                         E-mail:=20
      </PRE></BLOCKQUOTE><PRE wrap=3D""><A =
class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:zander@fokus.fraunhofer.de">zander@fokus.fraunhofer.de</A=
>
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Fraunhofer FOKUS / =
METEOR                Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany                 =20
      </PRE></BLOCKQUOTE><PRE wrap=3D""><A class=3Dmoz-txt-link-abbrevia=
ted =
href=3D"http://www.fokus.fraunhofer.de/usr/sebastian.zander">www.fokus.f=
raunhofer.de/usr/sebastian.zander</A>
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">

      </PRE></BLOCKQUOTE><PRE wrap=3D"">
--
Help        <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wi=
sc.edu</A> and say "help<A class=3Dmoz-txt-link-rfc2396E =
href=3D"inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay=
">"=20
in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"</A>unsubscribe ipfix" in message body
Archive     <A class=3Dmoz-txt-link-freetext =
href=3D"http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/=
archive/</A>

    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
--
Help        <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wi=
sc.edu</A> and say "help<A class=3Dmoz-txt-link-rfc2396E =
href=3D"inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay=
">" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"</A>unsubscribe ipfix" in message body
Archive     <A class=3Dmoz-txt-link-freetext =
href=3D"http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/=
archive/</A>
  </PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C32936.5C47AD80--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun  3 11:19:39 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09135
	for <ipfix-archive@lists.ietf.org>; Tue, 3 Jun 2003 11:19:39 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19ND2y-0002Cm-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 03 Jun 2003 09:45:56 -0500
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 19ND2w-0002Ce-00
	for ipfix@net.doit.wisc.edu; Tue, 03 Jun 2003 09:45:54 -0500
Received: from cisco.com (ams-clip-vpn-dhcp4210.cisco.com [10.61.80.113])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h53EjYR11012;
	Tue, 3 Jun 2003 16:45:35 +0200 (CEST)
Message-ID: <3EDCB48D.40207@cisco.com>
Date: Tue, 03 Jun 2003 16:45:33 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: calato@riverstonenet.com, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] drawing the line between protocol and data model document
References: <1D3D2C371FCBD947A7897FABBD3533A566BA84@xsun01.ptp.hp.com> <3EB13485.3FA365D7@riverstonenet.com> <20030501162116.B33173@net.ohio-state.edu>
In-Reply-To: <20030501162116.B33173@net.ohio-state.edu>
Content-Type: multipart/alternative;
 boundary="------------070905010703060201050900"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.
--------------070905010703060201050900
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Mark,

>On Thu, May 01, 2003 at 10:51:49AM -0400, calato@riverstonenet.com wrote:
>
><snip>
>
>  
>
>>The richness of the protocol encoding specification is another
>>matter. The protocol would reference each element in the data
>>model and define exaclty how that element is encoded. In the above 
>>example, the protocol is free to encode that as an unsigned byte 
>>if the value is < 256. 
>>    
>>
>
>The ramifications of doing this with a template based system are a bit
>ugly.  Consider a flow with just 2 counters -- octets, packets.
>Each could have a 1 to 8 byte encoding.  That's a potential of 64
>different templates for representing 1 type of flow.
>
>This (at first glance) looks like it adds considerable cycles to the
>encode / decode process to save a few bytes in the transport.
>
>The current v9 spec appears to allow this, but only for IN_BYTES and
>IN_PKTS.
>
>  
>
>>                                          counter with length
>>   IN_BYTES                 1       N     N x 8 bits for bytes
>>                                          associated with an IP Flow
>>    
>>
>
>Is this true?  Benoit?
>  
>
I'm trying to catch up with my IPIFX emails; I know I'm late on this 
thread, which seems to have reached consensus as far as I can tell, but 
as this is a direct question to me, let me answer.
Actually, there are:
BYTES            1             4             field type for the 32 bit 
bytes counter
BYTES_64      23           8             field type for the 64 bit bytes 
counter

So the draft that you refer to needs a quick update.

Regards, Benoit



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


--------------070905010703060201050900
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Mark,
<blockquote type="cite"
 cite="mid20030501162116.B33173@net.ohio-state.edu">
  <pre wrap="">On Thu, May 01, 2003 at 10:51:49AM -0400, <a class="moz-txt-link-abbreviated" href="mailto:calato@riverstonenet.com">calato@riverstonenet.com</a> wrote:

&lt;snip&gt;

  </pre>
  <blockquote type="cite">
    <pre wrap="">The richness of the protocol encoding specification is another
matter. The protocol would reference each element in the data
model and define exaclty how that element is encoded. In the above 
example, the protocol is free to encode that as an unsigned byte 
if the value is &lt; 256. 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
The ramifications of doing this with a template based system are a bit
ugly.  Consider a flow with just 2 counters -- octets, packets.
Each could have a 1 to 8 byte encoding.  That's a potential of 64
different templates for representing 1 type of flow.

This (at first glance) looks like it adds considerable cycles to the
encode / decode process to save a few bytes in the transport.

The current v9 spec appears to allow this, but only for IN_BYTES and
IN_PKTS.

  </pre>
  <blockquote type="cite">
    <pre wrap="">                                          counter with length
   IN_BYTES                 1       N     N x 8 bits for bytes
                                          associated with an IP Flow
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Is this true?  Benoit?
  </pre>
</blockquote>
I'm trying to catch up with my IPIFX emails; I know I'm late on this
thread, which seems to have reached consensus as far as I can tell, but
as this is a direct question to me, let me answer.<br>
Actually, there are:<br>
BYTES&nbsp; &nbsp;&nbsp;  &nbsp;&nbsp;  &nbsp; &nbsp;  1 &nbsp;&nbsp;  &nbsp;&nbsp;  &nbsp;&nbsp;  &nbsp;&nbsp;  4 &nbsp;&nbsp;  &nbsp;&nbsp;  &nbsp;&nbsp;  &nbsp;&nbsp; field type for
the 32 bit bytes counter<br>
BYTES_64&nbsp;&nbsp;  &nbsp;&nbsp;  23&nbsp;&nbsp;  &nbsp;&nbsp;  &nbsp;&nbsp;&nbsp;&nbsp;  8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; field type for the 64 bit
bytes counter<br>
<br>
So the draft that you refer to needs a quick update.<br>
<!--[endif]--><o:idmap v:ext="edit" data="3"></o:idmap><br>
Regards, Benoit<br>
<br>
<br>
<br>
<blockquote type="cite"
 cite="mid20030501162116.B33173@net.ohio-state.edu">
  <pre wrap="">

mark

--
Help        <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help<a class="moz-txt-link-rfc2396E" href="inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay">" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"</a>unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>
  </pre>
</blockquote>
<br>
</body>
</html>

--------------070905010703060201050900--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun  3 11:46:54 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10976
	for <ipfix-archive@lists.ietf.org>; Tue, 3 Jun 2003 11:46:54 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19NDbQ-0002w6-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 03 Jun 2003 10:21:33 -0500
Received: from atlrel9.hp.com ([156.153.255.214])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19NDbP-0002vz-00
	for ipfix@net.doit.wisc.edu; Tue, 03 Jun 2003 10:21:31 -0500
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel9.hp.com (Postfix) with ESMTP
	id B3A0E1C01445; Tue,  3 Jun 2003 11:21:30 -0400 (EDT)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP
	id 7A2811C00B46; Tue,  3 Jun 2003 11:21:30 -0400 (EDT)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <L5NRWBFB>; Tue, 3 Jun 2003 11:21:30 -0400
Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50296000A@xsun01.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Benoit Claise'" <bclaise@cisco.com>, Mark Fullmer <maf@eng.oar.net>
Cc: calato@riverstonenet.com, ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] drawing the line between protocol and data model docu
	ment
Date: Tue, 3 Jun 2003 11:21:26 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C329E3.CCA646B0"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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_01C329E3.CCA646B0
Content-Type: text/plain;
	charset="iso-8859-1"

I'd agree w/ Benoit.  In a template based approach, it is beneficial to
define a SINGLE encoding for
any given data type (e.g. 1 byte for byte, 2 bytes for short, etc.)
 
If we were doing TLV instead of templates, that would be a different matter.
 
-- Jeff

-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, June 03, 2003 7:46 AM
To: Mark Fullmer
Cc: calato@riverstonenet.com; ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] drawing the line between protocol and data model
document


Mark, 

On Thu, May 01, 2003 at 10:51:49AM -0400,  calato@riverstonenet.com
<mailto:calato@riverstonenet.com>  wrote:



<snip>



  

The richness of the protocol encoding specification is another

matter. The protocol would reference each element in the data

model and define exaclty how that element is encoded. In the above 

example, the protocol is free to encode that as an unsigned byte 

if the value is < 256. 

    



The ramifications of doing this with a template based system are a bit

ugly.  Consider a flow with just 2 counters -- octets, packets.

Each could have a 1 to 8 byte encoding.  That's a potential of 64

different templates for representing 1 type of flow.



This (at first glance) looks like it adds considerable cycles to the

encode / decode process to save a few bytes in the transport.



The current v9 spec appears to allow this, but only for IN_BYTES and

IN_PKTS.



  

                                          counter with length

   IN_BYTES                 1       N     N x 8 bits for bytes

                                          associated with an IP Flow

    



Is this true?  Benoit?

  

I'm trying to catch up with my IPIFX emails; I know I'm late on this thread,
which seems to have reached consensus as far as I can tell, but as this is a
direct question to me, let me answer.
Actually, there are:
BYTES            1             4             field type for the 32 bit bytes
counter
BYTES_64      23           8             field type for the 64 bit bytes
counter

So the draft that you refer to needs a quick update.
<!--[endif]-->
Regards, Benoit







mark



--

Help         mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say "help " in message body
<inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay> 

Unsubscribe mailto:majordomo@net.doit.wisc.edu and say

"unsubscribe ipfix" in message body

Archive      http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/> 

  



------_=_NextPart_001_01C329E3.CCA646B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE></TITLE>

<META content=3D"MSHTML 5.50.4731.2200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D337032215-03062003><FONT face=3DArial =
color=3D#0000ff size=3D2>I'd=20
agree w/ Benoit.&nbsp; In a template based approach, it is beneficial =
to define=20
a SINGLE encoding for</FONT></SPAN></DIV>
<DIV><SPAN class=3D337032215-03062003><FONT face=3DArial =
color=3D#0000ff size=3D2>any=20
given data type (e.g. 1 byte for byte, 2 bytes for short,=20
etc.)</FONT></SPAN></DIV>
<DIV><SPAN class=3D337032215-03062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D337032215-03062003><FONT face=3DArial =
color=3D#0000ff size=3D2>If we=20
were doing TLV instead of templates, that would be a different=20
matter.</FONT></SPAN></DIV>
<DIV><SPAN class=3D337032215-03062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D337032215-03062003><FONT face=3DArial =
color=3D#0000ff size=3D2>--=20
Jeff</FONT></SPAN></DIV>
<BLOCKQUOTE>
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Benoit Claise=20
  [mailto:bclaise@cisco.com]<BR><B>Sent:</B> Tuesday, June 03, 2003 =
7:46=20
  AM<BR><B>To:</B> Mark Fullmer<BR><B>Cc:</B> calato@riverstonenet.com; =

  ipfix@net.doit.wisc.edu<BR><B>Subject:</B> Re: [ipfix] drawing the =
line=20
  between protocol and data model document<BR><BR></FONT></DIV>Mark,=20
  <BLOCKQUOTE cite=3D"mid20030501162116.B33173@net.ohio-state.edu" =
type=3D"cite"><PRE wrap=3D"">On Thu, May 01, 2003 at 10:51:49AM -0400, =
<A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:calato@riverstonenet.com">calato@riverstonenet.com</A> =
wrote:

&lt;snip&gt;

  </PRE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">The richness of the =
protocol encoding specification is another
matter. The protocol would reference each element in the data
model and define exaclty how that element is encoded. In the above=20
example, the protocol is free to encode that as an unsigned byte=20
if the value is &lt; 256.=20
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
The ramifications of doing this with a template based system are a bit
ugly.  Consider a flow with just 2 counters -- octets, packets.
Each could have a 1 to 8 byte encoding.  That's a potential of 64
different templates for representing 1 type of flow.

This (at first glance) looks like it adds considerable cycles to the
encode / decode process to save a few bytes in the transport.

The current v9 spec appears to allow this, but only for IN_BYTES and
IN_PKTS.

  </PRE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">                           =
               counter with length
   IN_BYTES                 1       N     N x 8 bits for bytes
                                          associated with an IP Flow
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
Is this true?  Benoit?
  </PRE></BLOCKQUOTE>I'm trying to catch up with my IPIFX emails; I =
know I'm=20
  late on this thread, which seems to have reached consensus as far as =
I can=20
  tell, but as this is a direct question to me, let me =
answer.<BR>Actually,=20
  there are:<BR>BYTES&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp; &nbsp; 1=20
  &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; 4 &nbsp;&nbsp;=20
  &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; field type for the 32 bit =
bytes=20
  counter<BR>BYTES_64&nbsp;&nbsp; &nbsp;&nbsp; 23&nbsp;&nbsp; =
&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;=20
  =
8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  field type for the 64 bit bytes counter<BR><BR>So the draft that you =
refer to=20
  needs a quick update.<BR>&lt;!--[endif]--&gt;<O:IDMAP data=3D"3"=20
  v:ext=3D"edit"></O:IDMAP><BR>Regards, Benoit<BR><BR><BR><BR>
  <BLOCKQUOTE cite=3D"mid20030501162116.B33173@net.ohio-state.edu" =
type=3D"cite"><PRE wrap=3D"">
mark

--
Help        <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wi=
sc.edu</A> and say "help<A class=3Dmoz-txt-link-rfc2396E =
href=3D"inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay=
">" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"</A>unsubscribe ipfix" in message body
Archive     <A class=3Dmoz-txt-link-freetext =
href=3D"http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/=
archive/</A>
  </PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C329E3.CCA646B0--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun  3 12:09:02 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12337
	for <ipfix-archive@lists.ietf.org>; Tue, 3 Jun 2003 12:09:02 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19NE1A-0003VC-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 03 Jun 2003 10:48:08 -0500
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19NE17-0003Uz-00
	for ipfix@net.doit.wisc.edu; Tue, 03 Jun 2003 10:48:06 -0500
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h53Fm2VI027433
	for <ipfix@net.doit.wisc.edu>; Tue, 3 Jun 2003 17:48:02 +0200 (CEST)
Received: from [10.1.1.128] (n-quittek.office [10.1.1.128])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1EBE7A9B5A
	for <ipfix@net.doit.wisc.edu>; Tue,  3 Jun 2003 17:36:08 +0200 (CEST)
Date: Tue, 03 Jun 2003 17:50:04 +0200
From: Juergen Quittek <quittek@ccrle.nec.de>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] IPFIX requirements - final list of issues
Message-ID: <28250421.1054662604@[10.1.1.128]>
X-Mailer: Mulberry/2.1.2 (Win32)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==========28276029=========="
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

--==========28276029==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Dear all,

Attached you will find the list of proposed changes from version -09 to
version -10 of the IPFIX requirements. Benoit and I compiled it and
added some new wordings where required. Most things are already agreed
on the list, but please have a look at issues #5, #11, #12 and #13.

If there are no objections by Thursday,
I will post a new version on Friday.

Cheers,

    Juergen

--==========28276029==========
Content-Type: text/plain; charset=us-ascii; name="IPFIX-reqs-issues.txt"
Content-Disposition: attachment; filename="IPFIX-reqs-issues.txt"; size=21039
Content-Transfer-Encoding: 7bit

==============================
IPFIX Requirements Open Issues
==============================



========================================================================
1. timestamp resolution reference
========================================================================
Problem Description:
------------------------------------------------------------------------
   5.4.  Timestamps

     The metering process MUST be able to generate timestamps for the
     first and the last observation of a packet of a flow at the
     observation point. The timestamp resolution MUST be at least the one
     of the sysUpTime [RFC1213], which is one centisecond.

I think I'd rather see a reference to RFC3418 instead of RFC1213.
We can do so by RFC-Editor note. May want to check with authors too.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace ref to RFC1213 by ref to RFC3418
========================================================================
Status: solution committed
========================================================================



========================================================================
2. reporting TOS/traffic class octet or reporting DSCP
========================================================================
Problem Description:
------------------------------------------------------------------------
On page 14 I see:

      9. type of service octet (in case of IPv4), traffic class
         octet (in case of IPv6)
     
Is that not better state as 

      9. DSCP, which is set in the type of service octet (in case of IPv4),
         or in the traffic class octet (in case of IPv6)
========================================================================
Suggested solution:
------------------------------------------------------------------------
   According to RFC 2474, the DSCP covers only 6 bit of the type of 
   service octet, and in some cases you want to see the entire byte.
   This is be pointed out by a comment added to item 9.:
   "According to RFC 2474 these octets include the DiffServ Code Point
   that has a length of 6 bit."
========================================================================
Status: solution committed
========================================================================



========================================================================
3. location of reference to RFC 2119
========================================================================
Problem Description:
------------------------------------------------------------------------
   I would prefer to see the paragraph referencing RFC 2119 in section 2.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   Move reference to RFC 2119 to section 2
========================================================================
Status: solution committed
========================================================================



========================================================================
4. bad wording in section 6.3.3, last paragraph
========================================================================
Problem Description:
------------------------------------------------------------------------
   Last paragraph in section 6.3.3 needs to be reworded.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace
     "The security threats from which these 3 requirements are deducted 
      are explained in the "Security Considerations" (Section 10)."
   by
     "The security requirements have been derived from an analysis of
      potential security threads. The analysis is summarized in
      Section 10." 
========================================================================
Status: solution committed
========================================================================



========================================================================
5. describe potential problem of faked DoS attack
========================================================================
Problem Description:
------------------------------------------------------------------------
   In section 10.2, an important point is left unsaid.  If the injection of 
IPFIX traffic fool the network provided into thinking that a DOS attack is 
underway, the countermeasures employed by the network provider may actually 
deny service to real customers.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace the entire section 10.2 Forgery of Flow Records:
     "If flow records are used in accounting and security applications,
      there are potentially strong incentives to forge exported IPFIX flow
      records (for example to save money or prevent the detection of an
      attack). This can be done either by altering flow records on the path
      or by injecting forged flow records that pretend to be originated by
      the original exporting process. In order to make an IPFIX protocol
      resistant against such attacks, authentication and integrity must be
      provided, as specified in section 6.3.3.

      Special caution is required if security applications rely on flow
      measurements. With forged flow records it is possible to trick on
      security applications. It is for instance possible to pretend that a
      DoS attack happens without even launching a real attack."
   by
     "If flow records are used in accounting and/or security applications, 
      there are potentially strong incentives to forge exported IPFIX 
      flow records (for example to save money or prevent the detection 
      of an attack). This can be done either by altering flow records 
      on the path or by injecting forged flow records that pretend to 
      be originated by the original exporting process. 

      Special caution is required if security applications rely on flow
      measurements. With forged flow records it is possible to trick on 
      security applications. It is for instance possible to pretend that 
      a DoS attack happens without even launching a real attack. If such 
      an injection of IPFIX traffic flow records fools the security 
      application, pretending that a DoS attack is underway, then the 
      countermeasures employed by the security application may actually 
      deny useful non-malicious services.

      In order to make an IPFIX protocol resistant against such attacks,
      authentication and integrity must be provided, as specified in 
      section 6.3.3."
========================================================================
Status: solution to be agreed on
========================================================================



========================================================================
6. location of appendix
========================================================================
Problem Description:
------------------------------------------------------------------------
   The appendix needs to be moved up in the document.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   move appendix above references, copyright, and authors' addresses
========================================================================
Status: solution to be committed
========================================================================



========================================================================
7. consistency of appendix
========================================================================
Problem Description:
------------------------------------------------------------------------
   The appendix is outdated. Alignment with the text sections and
   coverage of all requirements need to be checked and fixed.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   --- 5.2 Sampling
   Add note (j): "If sampling is supported, sampling configuration 
   changes MUST be indicated to all collecting processes"

   --- 5.3 Overload behavior
   Add note (k): "If overload is supported and it induces changes in 
   the metering process behavior, the overload behavior MUST be 
   clearly defined"

   --- Requirement on packet fragmentation state at the meter is 
   missing (section 5.8)
   Add "5.8 Packet Fragmentation state O O - - - O"

   --- 6.1 Dropped packet counter:  This requirement appears as a MUST 
   in the appendix, but it is a MAY in current section 6.1
   Replace with: "6.1 Dropped packet counter (h,i) O O O O O O"

   --- 6.1 ToS byte and DSCP: they appear as separate requirements in 
   the appendix. Besides, Traffic Class (IPv6) is not mentioned.
   Remove line "6.1 ToS Byte M S M O M M" and leave only 
   "6.1 DSCP (a) M S M O M M"

   --- 6.1 BGP AS# is given as MUST in the appendix, but it is a 
   MAY in current section 6.1
   Replace "6.1 BGP AS# - S M - - M" with the following line:
   "6.1 src/dst/next hop BGP AS # - O O - - O"

   --- For the Information Model, requirements on ICMP type and 
   in/out interface are missing:
   Add "6.1 ICMP type and code (l) S S - S S S"
   Add note: "(l) If protocol type is ICMP"

   Add "6.1 input/output interface (m) S S S S S S"
   Add note: "(m) This requirement does not apply if the observation 
   point is located at a probe device"

   --- For the Data Model the following requirement is missing:
   "6.2 Independency of the transport protocol S S S S S S"

   --- "6.7 Anonymization O O O O O O"
   Add note: "(n) anonymization MUST be clearly indicated to all 
   receiving collecting processes"

   --- Configuration requirements for metering process:
   Add "7.1 Config Overload behavior (a) O O O O O O"

   --- Configuration reqs. for exporting process:
   Config Notifications and Config Anonymization should be changed 
   to SHOULD (they are listed as MAY)

   Add the following missing reqs:
   "Config Collecting Processes S S S S S S"
   "Config reporting interval (a) S S S S S S"
========================================================================
Status: solution to be committed
========================================================================



========================================================================
8. More concrete definition of byte counter
========================================================================
Problem Description:
------------------------------------------------------------------------
This document goes to a lot of trouble to say exactly what is
exported (e.g. what fields, etc), except for two cases:

      8. byte counter
         Which bytes of a packet are counted MUST be defined exactly.

This document is defining what fields are being reported on;
why can't it also define these two things that must also be
defined?  Is it useful to have different ipfix protocols exporting
different measurements?
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace "Which bytes of a packet are counted MUST be defined 
   exactly." by "The sum of the total length in bytes of all IP packets 
   belonging to the flow. The total length of a packet covers 
   IP header and IP payload."
========================================================================
Status: solution to be committed
========================================================================



========================================================================
9. More concrete definition of multicast replication factor
========================================================================
Problem Description:
------------------------------------------------------------------------
This document goes to a lot of trouble to say exactly what is
exported (e.g. what fields, etc), except for two cases:

     20. multicast replication factor
         the number of outgoing packets originating from a single   
         incoming multicast packet. This is a dynamic property of     
         multicast flows, that may change over time. For unicast flows  
         it has the constant value 1. The computation of the factor MUST
         be clearly defined.

This document is defining what fields are being reported on;
why can't it also define these two things that must also be
defined?  Is it useful to have different ipfix protocols exporting
different measurements?
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace last sentence by "The reported value MUST be the value of the
   factor at the time the flow record is exported."
========================================================================
Status: solution to be committed
========================================================================



========================================================================
10. More concrete definition of BGP-related attributes
========================================================================
Problem Description:
------------------------------------------------------------------------
Also, at the end of 6.1 it kind of says "Plus other stuff related to inter-AS
routing if you want".  It's already in the MAY section; can't they just
list some concrete items related to inter-AS routing as 27, 28, ...?
I don't think it's useful to say what amounts to "plus anything else that
you might feel like adding that you think is relevant", since that doesn't
encourage different people to make the same choices.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   add three more MAY attributes:
   - 27. source BGP Autonomous System number [RFC1771]
   - 28. destination BGP Autonomous System number
   - 29. next hop BGP Autonomous System number
========================================================================
Status: solution to be committed
========================================================================



========================================================================
11. Address the reliability issue of usage based accounting
========================================================================
Problem Description:
------------------------------------------------------------------------
The applications include usage-based accounting.  They should cite RFC 2975,
and indicate that the particular niche for usage-based accounting would not
be met if reliability was not very high.  Section 5.1 reliability requirements
do not meet the needs, nor do the timestamping of first and last packet of
a flow, because the flow may have been mischaracterized and that is first and
last of different flows.  The way to satisfy this issue is to caveat the
discussion of usage-based accounting with strong words on reliability that
counter the comments on lesser reliability and more probabilistic techniques
for other applications of ipfix.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   remove from section 3:
     "Please note, that the described applications can have a large number
      of differing implementations. Requirement details or the weighting of
      requirements could differ for specific implementations. Therefore we
      derive the requirements from the general functionality of the
      selected applications."
   append to section 3.:
     "The list of applications should lead to a better understanding of
      the requirements which is particularly important when designing or
      implementing traffic flow metering functions. A detailed overview
      of which requirement was derived from which application(s) is given
      in the appendix.

      Please note, that the described applications can have a large 
      number of differing implementations. Requirement details or 
      requirement significance (MANDATORY (MUST), RECOMMENDED (SHOULD), 
      OPTIONAL (MAY)) could differ for specific implementations and/or 
      for specific application scenarios. Therefore we derive the 
      requirements from the general functionality of the selected 
      applications. Some particular cases will even mandate more 
      stringent requirements than the ones defined in this 
      document. For example, usage-based accounting is certainly the 
      application that will probably mandate the highest degree of 
      reliability amonst the applications discussed below. The 
      reliability reqirements defined in sections 5.1 and 6.3.2. are
      not sufficient to guarantee the level of reliability that is
      needed for many usage-based accounting systems. Particular
      reliability requirements for accounting systems are discussed 
      in [RFC2975]."
   add reference to RFC 2975 to References section
========================================================================
Status: solution to be agreed on
========================================================================



========================================================================
12. Confidentiality from SHOULD to MUST
========================================================================
Problem Description:
------------------------------------------------------------------------
Requirements on the ipfix implementation - the document is long and I wonder if
the working group really meant the protocol's confidentiality and anonymization
features to be so optional -  SHOULD confidentiality, MAY anonymization.
Just for implementation.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   insert in section 1. Introduction after third sentence:
     "They serve as input to the standardization of an IPFIX protcol."

   append to section 1, Introduction:
     "Many requirements in this document are not explicitly
      stated as IPFIX protocol requirements, but as requirements
      for the metering process, the exporting process, or for
      other traffic measurement components. However, every
      requirement that needs support from the IPFIX protocol
      MUST be covered by the IPFIX protocol specification
      and related standard documents independent of the 
      significance of the requirement, which can be MANDATORY (MUST), 
      RECOMMENDED (SHOULD), or OPTIONAL (MAY).

      Note that the protocol specification and related standard 
      documents themselves also assign significance attributes to its 
      features, such that a protocol implementation does not 
      necessarily need to implement all features. However, these 
      significance attributes need to match the significance of the 
      corresponding requirements."
========================================================================
Status: solution to be agreed on
========================================================================



========================================================================
13. Anonymization from MAY to MUST
========================================================================
Problem Description:
------------------------------------------------------------------------
Requirements on the ipfix implementation - the document is long and I wonder if
the working group really meant the protocol's confidentiality and anonymization
features to be so optional -  SHOULD confidentiality, MAY anonymization.
Just for implementation.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   see solution of issue 12
========================================================================
Status: solution to be agreed on
========================================================================





--==========28276029==========--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun  3 12:21:06 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13064
	for <ipfix-archive@lists.ietf.org>; Tue, 3 Jun 2003 12:21:06 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19NEHH-0003rd-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 03 Jun 2003 11:04:47 -0500
Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail3.alcatel.fr)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19NEHF-0003rN-00
	for ipfix@net.doit.wisc.edu; Tue, 03 Jun 2003 11:04:45 -0500
Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163])
	by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id h53G4h5R030554
	for <ipfix@net.doit.wisc.edu>; Tue, 3 Jun 2003 18:04:43 +0200
Received: from alcatel.fr ([172.26.193.41])
          by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a)
          with ESMTP id 2003060318044193:6473 ;
          Tue, 3 Jun 2003 18:04:41 +0200 
Message-ID: <3EDCC71A.40205@alcatel.fr>
Date: Tue, 03 Jun 2003 18:04:42 +0200
From: Alban.Couturier@alcatel.fr
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] draft on signaling and QoS measurement
X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at
 06/03/2003 18:04:42,
	Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at
 06/03/2003 18:04:43,
	Serialize complete at 06/03/2003 18:04:43
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Virus-Scanned: by amavisd-new
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Dear all,

I just proposed in NSIS an ID about a signaling based solution to make 
QoS measurement. This solution requires exportations of flow information 
and I refer to ipfix as a candidate to complete this architecture.
I'd like to know if people from ipfix community are interrested in this 
solution and would support this work, contribute...

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-couturier-nsis-measure-00.txt

Best regards

Alban Couturier


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun  4 18:21:01 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16066
	for <ipfix-archive@lists.ietf.org>; Wed, 4 Jun 2003 18:21:01 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Ng1f-0001Fy-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 04 Jun 2003 16:42:31 -0500
Received: from [130.216.191.4] (helo=mailhost2.auckland.ac.nz)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Ng1c-0001Fn-00
	for ipfix@net.doit.wisc.edu; Wed, 04 Jun 2003 16:42:28 -0500
Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61])
	by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h54LgH8W010613;
	Thu, 5 Jun 2003 09:42:17 +1200 (NZST)
Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123])
	by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.5-GR)
	with ESMTP id AQT19936;
	Thu, 5 Jun 2003 09:42:16 +1200 (NZST)
Received: (from apache@localhost)
	by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h54LgFp27332;
	Thu, 5 Jun 2003 09:42:15 +1200
X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f
Received: from wallaby.caida.org (wallaby.caida.org [192.172.226.111]) by
	hotlava.auckland.ac.nz (Horde) with HTTP for
	<jbro111@hotlava.auckland.ac.nz>; Thu,  5 Jun 2003 09:42:15 +1200
Message-ID: <1054762935.fc66d19973b57@hotlava.auckland.ac.nz>
Date: Thu,  5 Jun 2003 09:42:15 +1200
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
To: Juergen Quittek <quittek@ccrle.nec.de>
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] IPFIX requirements - final list of issues
References: <28250421.1054662604@[10.1.1.128]>
In-Reply-To: <28250421.1054662604@[10.1.1.128]>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP:  192.172.226.111
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


Hello Juergen:

> Attached you will find the list of proposed changes from version -09 to
> version -10 of the IPFIX requirements. Benoit and I compiled it and
> added some new wordings where required. Most things are already agreed
> on the list, but please have a look at issues #5, #11, #12 and #13.
> 
> If there are no objections by Thursday,
> I will post a new version on Friday.

I've read through all the changes, they seem OK to me.
One slight suggestion for change 12. Confidentiality (and 13. Anonymisation,
I guess):  The last sentence seems confusing, how about

  However, the implementations significance atributes need to match those 
  of the corresponding IPFIX requirements.

As it is, I found that sentence confusing in the version you distributed.

Once you've published this revision, could you please send a note to
Randy and Bert telling them what changes have been made, and asking them to
send it back to IESG?  Thanks.

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun  5 04:58:10 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12001
	for <ipfix-archive@lists.ietf.org>; Thu, 5 Jun 2003 04:58:10 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19NqC0-0006A8-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 05 Jun 2003 03:33:52 -0500
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19NqBy-00069o-00
	for ipfix@net.doit.wisc.edu; Thu, 05 Jun 2003 03:33:51 -0500
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h558XWVI001571;
	Thu, 5 Jun 2003 10:33:34 +0200 (CEST)
Received: from [10.1.1.128] (n-quittek.office [10.1.1.128])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id BB7A0AA4CC; Thu,  5 Jun 2003 10:21:21 +0200 (CEST)
Date: Thu, 05 Jun 2003 10:35:40 +0200
From: Juergen Quittek <quittek@ccrle.nec.de>
To: Nevil Brownlee <n.brownlee@auckland.ac.nz>
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] IPFIX requirements - final list of issues
Message-ID: <3558787.1054809340@[10.1.1.128]>
In-Reply-To: <1054762935.fc66d19973b57@hotlava.auckland.ac.nz>
References:  <1054762935.fc66d19973b57@hotlava.auckland.ac.nz>
X-Mailer: Mulberry/2.1.2 (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 <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Nevil,

-- Nevil Brownlee wrote on 05 June 2003 09:42 +1200:

>
> Hello Juergen:
>
>> Attached you will find the list of proposed changes from version -09 to
>> version -10 of the IPFIX requirements. Benoit and I compiled it and
>> added some new wordings where required. Most things are already agreed
>> on the list, but please have a look at issues #5, #11, #12 and #13.
>>
>> If there are no objections by Thursday,
>> I will post a new version on Friday.
>
> I've read through all the changes, they seem OK to me.
> One slight suggestion for change 12. Confidentiality (and 13. Anonymisation,
> I guess):  The last sentence seems confusing, how about
>
>   However, the implementations significance atributes need to match those
>   of the corresponding IPFIX requirements.

Thanks. This sounds much better than the original sentence.

> As it is, I found that sentence confusing in the version you distributed.
>
> Once you've published this revision, could you please send a note to
> Randy and Bert telling them what changes have been made, and asking them to
> send it back to IESG?  Thanks.

OK. I will do so.

Cheers,

    Juergen


> Cheers, Nevil
>
> -----------------------------------------------------------------------
>    Nevil Brownlee                   Director, Technology Development
>    Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
>    FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
>
>
> -------------------------------------------------
> This mail sent through University of Auckland
> http://www.auckland.ac.nz/



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun  5 12:08:04 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04741
	for <ipfix-archive@lists.ietf.org>; Thu, 5 Jun 2003 12:08:04 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Nwz4-0002NH-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 05 Jun 2003 10:48:58 -0500
Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Nwz2-0002NB-00
	for ipfix@net.doit.wisc.edu; Thu, 05 Jun 2003 10:48:56 -0500
Date: Thu, 5 Jun 2003 10:48:56 -0500
From: Dave Plonka <plonka@doit.wisc.edu>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] info/data model status, con-call minutes
Message-ID: <20030605104856.A8670@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
X-Organization: University of Wisconsin-Madison, DoIT Network Services
X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL)
X-URL: http://net.doit.wisc.edu/~plonka/
X-VMS-Error: %SYSTEM-F-BADDATA, invalid data (00000000) at 00001022
X-Shakespearean-Insult: Thou reeky ill-nurtured varlet
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


IPFIXers,

I joined in on a conference call, to serve as scribe for minutes, on
this past tuesday with the editors of the IPFIX Information/Data Model
draft (formerly known as: draft-ietf-ipfix-data).

Below please find the minutes that I prepared, to keep the
WG/mailing-list participants up to date on the status of that
document.

Thanks,
Dave

----------------------------------------------------------------------

The call began Tue Jun  3 14:30 CDT 2003 and included the following
document editors Paul Calato, Jeff Meyer, Juergen Quittek, and
Dave Plonka served as the scribe.

The following topics regarding the Information/Data Model draft were discussed:

1) List of Attributes
   ------------------

   It was suggested that we discuss the procedure for selecting the
   list of flow attributes and to define what is the scope of the
   document concerning these attributes.

   It was noted that the draft-ietf-ipfix-data-01 document has expired
   (http://www.ietf.org/internet-drafts/draft-ietf-ipfix-data-01.txt),
   and only the "-00" version is available here:

      http://ipfix.doit.wisc.edu/data/draft-ietf-ipfix-data-00.txt

   The editors considered whether it would be better to refer to it
   as the Information rather than Data Model.

   Juergen pointed out that there is an existing RFC (RFC3444:
   http://www.ietf.org/rfc/rfc3444.txt) "On the Difference between
   Information Models and Data Models" which should clear up the
   meaning and lead to a decision on this.

   [That RFC was left to be read afterward.]

   Generally, it was agreed that the document should describe which
   information elements (ie. flow attributes) map to which (primitive)
   IPFIX data types.

2) Structure of attribute specification (enumeration, data type, semantics)
   ------------------------------------

   It was generally agreed that basic data types should be defined as
   primitive types in the protocol specification draft.  However, there
   was some discussion as to how much type information should be in
   this document instead.

   It was noted that the chairs have been encouraging that the WG
   produce protocol specification document (slated for standards track)
   and a more often changing information/data model document.  This
   should enable new attributes to be added without the requirement to
   revise the base protocol specification document.

   Some participants suggested that they would like the this info model
   document to define both semantics and type, to make the protocol as
   general a "data carrier" as possible.

   It was mentioned however that the protocol specification should
   define the type and this info/data model document simply make
   normative references to those types as defined in that protocol
   spec.  This would reduce the chance of potentially conflicting
   definitions between the protocol and info/data model documents.
   Likely, the protocol spec. needs to completely define the encodings
   and all behavior (eg. overflow) for each type.

3) Template
   --------

   A possible template (such as an XML stanza) for flow attribute
   definitions was considered.

   Jeff offered a sample from IPDR:
      http://www.ipdr.org/documents/ipfix/infomodel/ipfix_info.xsd

   It was generally agreed that the flow attribute template should
   include the folling mandatory fields:

     a) Name, eg. name="sourceAddress"
     b) Type, eg. type="IPFIX:ipV4Addr"
              (types glommed from W3C XMLSchema + some ipdr add's)
     c) Semantics: eg. <annotation><documentation></documentation></annotation>
     d) ID

   also, the following option fields were recognized:

     e) Range, eg. a qualifier, perhaps more limiting than that of the primitive
     f) Enumeration, 1 => foo, 2 => bar, 3 => baz, etc.
        Enumeration and Range are mutually exclusive.
     g) Units, eg. packets, bytes,
     h) Reference: eg. BGP id from such-and-such RFC, etc.
     i) Vendor ID

   It was noted that enumerations have been defined by XML schema, and
   therefore that syntax might be a useful precedent.

   That said, it was also noted that ultimately the WG must care more
   about the text-rendered description rather than one that is XML
   coded, since our deliverably is a plain-text Internet Draft or RFC.

   The editors will explore defining the attributes in XML and rendering
   them to plain text suitable for the I-D.

   Regarding the optional Vendor ID, which has been suggested for
   extensibility, the editors will either include it (or not) in their
   next info/data draft revision and give the WG/mailing-list
   participants the opportunity to weigh-in either for (or against)
   that option.  Perhaps it should be called a Namespace rather than
   a Vendor?  It was thought to consider DIAMETER'S solution to this,
   with the default being the IETF-defined Vendor/Namespace (if none
   other is speicifed.)
   
4) XML-coded attribute description in appendix
   -------------------------------------------

   This topic was generally covered in previous discussion.  IPDR has a
   number of precedents for defining things based upon W3C-defined
   XML.  These might be used by the info/data document editors where
   appropriate/feasible.

5) Review of the existing attributes (defined in existing WG documents)
   ---------------------------------

   A volunteer was requested to review the existing flow attributes
   defined in the existing Requirements (draft-ietf-ipfix-reqs), Data
   Model (draft-ietf-ipfix-data), and NetFlow v9
   (draft-bclaise-netflow-9-00) documents, and to prepare a merged list
   for use by the document editors.

   Paul Calato accepted this responsibility.
   Jeff Meyer is willing to do the transliation of that list into XML.

   It was proposed that the flow attribute namespace be "camelback",
   which is initial lower-case and then upper-case as the first letter
   of subsequent words, eg. "ipV4Address".

   Dave Plonka offered to review RFC3470 ("Guidelines for the Use of
   Extensible Markup Language (XML) within IETF Protocols"), to
   determine whether or not we can make normative references to W3C
   documents (for the primitive types).  If not, what do we do instead?

   Paul agreed that it would be useful to annotate the list with info
   about the source for each attribute, to aid in the tracking of
   document changes.

   Following the production of this initial list, the info/data model
   document editors plan to identify what's missing, what's perhaps
   unnecessary, and get feedback from the WG participants.

6) Document submission schedule
   ----------------------------

   June 23rd deadline for new "-00" revision for the 57th IETF meeting.

   The editors plan to produce a new revision by that deadline, and submit
   it by either its new name (Information Model) or as the "-02" revision
   of the previous document named draft-ietf-ipfix-data (edited by Paul
   Calato and KC Norseth), which has since expired.

We signed off from the call Tue Jun  3 ~16:00 CDT 2003

----------------------------------------------------------------------

-- 
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  Thu Jun  5 12:35:46 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05632
	for <ipfix-archive@lists.ietf.org>; Thu, 5 Jun 2003 12:35:46 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19NxTb-0003BF-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 05 Jun 2003 11:20:31 -0500
Received: from relay.pair.com ([209.68.1.20])
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 19NxTZ-0003B6-00
	for ipfix@net.doit.wisc.edu; Thu, 05 Jun 2003 11:20:30 -0500
Received: (qmail 14523 invoked from network); 5 Jun 2003 16:20:28 -0000
Received: from 207-237-237-207.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.237.207)
  by relay.pair.com with SMTP; 5 Jun 2003 16:20:28 -0000
X-pair-Authenticated: 207.237.237.207
Received: from sphynx (sphynx [192.168.0.64])
	by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h55GKT704015;
	Thu, 5 Jun 2003 12:20:29 -0400
From: "Carter Bullard" <carter@qosient.com>
To: <plonka@doit.wisc.edu>, <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] info/data model status, con-call minutes
Date: Thu, 5 Jun 2003 12:20:20 -0400
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607EA3E@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.4510
Importance: Normal
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED66153E62@ptah.newyork.qosient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Hey Dave,
Editors generally edit existing documents, but it
sounds to me that you guys are writing new material
that has not yet been presented as a draft nor discussed
on the list.  If this is the case, then shouldn't
the call be open to more people?

Carter



> -----Original Message-----
> From: majordomo listserver 
> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Dave Plonka
> Sent: Thursday, June 05, 2003 11:49 AM
> To: ipfix@net.doit.wisc.edu
> Subject: [ipfix] info/data model status, con-call minutes
> 
> 
> 
> IPFIXers,
> 
> I joined in on a conference call, to serve as scribe for minutes, on
> this past tuesday with the editors of the IPFIX Information/Data Model
> draft (formerly known as: draft-ietf-ipfix-data).
> 
> Below please find the minutes that I prepared, to keep the
> WG/mailing-list participants up to date on the status of that
> document.
> 
> Thanks,
> Dave
> 
> ----------------------------------------------------------------------
> 
> The call began Tue Jun  3 14:30 CDT 2003 and included the following
> document editors Paul Calato, Jeff Meyer, Juergen Quittek, and
> Dave Plonka served as the scribe.
> 
> The following topics regarding the Information/Data Model 
> draft were discussed:
> 
> 1) List of Attributes
>    ------------------
> 
>    It was suggested that we discuss the procedure for selecting the
>    list of flow attributes and to define what is the scope of the
>    document concerning these attributes.
> 
>    It was noted that the draft-ietf-ipfix-data-01 document has expired
>    (http://www.ietf.org/internet-drafts/draft-ietf-ipfix-data-01.txt),
>    and only the "-00" version is available here:
> 
>       http://ipfix.doit.wisc.edu/data/draft-ietf-ipfix-data-00.txt
> 
>    The editors considered whether it would be better to refer to it
>    as the Information rather than Data Model.
> 
>    Juergen pointed out that there is an existing RFC (RFC3444:
>    http://www.ietf.org/rfc/rfc3444.txt) "On the Difference between
>    Information Models and Data Models" which should clear up the
>    meaning and lead to a decision on this.
> 
>    [That RFC was left to be read afterward.]
> 
>    Generally, it was agreed that the document should describe which
>    information elements (ie. flow attributes) map to which (primitive)
>    IPFIX data types.
> 
> 2) Structure of attribute specification (enumeration, data 
> type, semantics)
>    ------------------------------------
> 
>    It was generally agreed that basic data types should be defined as
>    primitive types in the protocol specification draft.  
> However, there
>    was some discussion as to how much type information should be in
>    this document instead.
> 
>    It was noted that the chairs have been encouraging that the WG
>    produce protocol specification document (slated for 
> standards track)
>    and a more often changing information/data model document.  This
>    should enable new attributes to be added without the requirement to
>    revise the base protocol specification document.
> 
>    Some participants suggested that they would like the this 
> info model
>    document to define both semantics and type, to make the protocol as
>    general a "data carrier" as possible.
> 
>    It was mentioned however that the protocol specification should
>    define the type and this info/data model document simply make
>    normative references to those types as defined in that protocol
>    spec.  This would reduce the chance of potentially conflicting
>    definitions between the protocol and info/data model documents.
>    Likely, the protocol spec. needs to completely define the encodings
>    and all behavior (eg. overflow) for each type.
> 
> 3) Template
>    --------
> 
>    A possible template (such as an XML stanza) for flow attribute
>    definitions was considered.
> 
>    Jeff offered a sample from IPDR:
>       http://www.ipdr.org/documents/ipfix/infomodel/ipfix_info.xsd
> 
>    It was generally agreed that the flow attribute template should
>    include the folling mandatory fields:
> 
>      a) Name, eg. name="sourceAddress"
>      b) Type, eg. type="IPFIX:ipV4Addr"
>               (types glommed from W3C XMLSchema + some ipdr add's)
>      c) Semantics: eg. 
> <annotation><documentation></documentation></annotation>
>      d) ID
> 
>    also, the following option fields were recognized:
> 
>      e) Range, eg. a qualifier, perhaps more limiting than 
> that of the primitive
>      f) Enumeration, 1 => foo, 2 => bar, 3 => baz, etc.
>         Enumeration and Range are mutually exclusive.
>      g) Units, eg. packets, bytes,
>      h) Reference: eg. BGP id from such-and-such RFC, etc.
>      i) Vendor ID
> 
>    It was noted that enumerations have been defined by XML schema, and
>    therefore that syntax might be a useful precedent.
> 
>    That said, it was also noted that ultimately the WG must care more
>    about the text-rendered description rather than one that is XML
>    coded, since our deliverably is a plain-text Internet Draft or RFC.
> 
>    The editors will explore defining the attributes in XML 
> and rendering
>    them to plain text suitable for the I-D.
> 
>    Regarding the optional Vendor ID, which has been suggested for
>    extensibility, the editors will either include it (or not) in their
>    next info/data draft revision and give the WG/mailing-list
>    participants the opportunity to weigh-in either for (or against)
>    that option.  Perhaps it should be called a Namespace rather than
>    a Vendor?  It was thought to consider DIAMETER'S solution to this,
>    with the default being the IETF-defined Vendor/Namespace (if none
>    other is speicifed.)
>    
> 4) XML-coded attribute description in appendix
>    -------------------------------------------
> 
>    This topic was generally covered in previous discussion.  
> IPDR has a
>    number of precedents for defining things based upon W3C-defined
>    XML.  These might be used by the info/data document editors where
>    appropriate/feasible.
> 
> 5) Review of the existing attributes (defined in existing WG 
> documents)
>    ---------------------------------
> 
>    A volunteer was requested to review the existing flow attributes
>    defined in the existing Requirements (draft-ietf-ipfix-reqs), Data
>    Model (draft-ietf-ipfix-data), and NetFlow v9
>    (draft-bclaise-netflow-9-00) documents, and to prepare a 
> merged list
>    for use by the document editors.
> 
>    Paul Calato accepted this responsibility.
>    Jeff Meyer is willing to do the transliation of that list into XML.
> 
>    It was proposed that the flow attribute namespace be "camelback",
>    which is initial lower-case and then upper-case as the first letter
>    of subsequent words, eg. "ipV4Address".
> 
>    Dave Plonka offered to review RFC3470 ("Guidelines for the Use of
>    Extensible Markup Language (XML) within IETF Protocols"), to
>    determine whether or not we can make normative references to W3C
>    documents (for the primitive types).  If not, what do we 
> do instead?
> 
>    Paul agreed that it would be useful to annotate the list with info
>    about the source for each attribute, to aid in the tracking of
>    document changes.
> 
>    Following the production of this initial list, the info/data model
>    document editors plan to identify what's missing, what's perhaps
>    unnecessary, and get feedback from the WG participants.
> 
> 6) Document submission schedule
>    ----------------------------
> 
>    June 23rd deadline for new "-00" revision for the 57th 
> IETF meeting.
> 
>    The editors plan to produce a new revision by that 
> deadline, and submit
>    it by either its new name (Information Model) or as the 
> "-02" revision
>    of the previous document named draft-ietf-ipfix-data 
> (edited by Paul
>    Calato and KC Norseth), which has since expired.
> 
> We signed off from the call Tue Jun  3 ~16:00 CDT 2003
> 
> ----------------------------------------------------------------------
> 
> -- 
> 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  Thu Jun  5 12:47:24 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05953
	for <ipfix-archive@lists.ietf.org>; Thu, 5 Jun 2003 12:47:24 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19NxgG-0003Pi-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 05 Jun 2003 11:33:36 -0500
Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19NxgE-0003Pa-00; Thu, 05 Jun 2003 11:33:34 -0500
Date: Thu, 5 Jun 2003 11:33:34 -0500
From: Dave Plonka <plonka@doit.wisc.edu>
To: ipfix@net.doit.wisc.edu
Cc: Carter Bullard <carter@qosient.com>
Subject: Re: [ipfix] info/data model status, con-call minutes
Message-ID: <20030605113334.A12398@doit.wisc.edu>
Reply-To: plonka@doit.wisc.edu
References: <5C8959A16A71B449AE793CF52FBBED66153E62@ptah.newyork.qosient.com> <5C8959A16A71B449AE793CF52FBBED6607EA3E@ptah.newyork.qosient.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607EA3E@ptah.newyork.qosient.com>; from carter@qosient.com on Thu, Jun 05, 2003 at 12:20:20PM -0400
X-Organization: University of Wisconsin-Madison, DoIT Network Services
X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL)
X-URL: http://net.doit.wisc.edu/~plonka/
X-VMS-Error: %SYSTEM-W-DRVEXISTS, device driver already loaded
X-Shakespearean-Insult: Thou currish crook-pated flax-wench
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


Hi Carter,

On Thu, Jun 05, 2003 at 12:20:20PM -0400, Carter Bullard wrote:
> Editors generally edit existing documents, but it
> sounds to me that you guys are writing new material
> that has not yet been presented as a draft nor discussed
> on the list.

It is an existing document, although it has expired.  It is the one
KC and Paul Calato edited, the latest revision mirrored is here:

   http://ipfix.doit.wisc.edu/data/draft-ietf-ipfix-data-00.txt

although ther is apparently a "-01" revision that has been lost track of.

As noted in the minutes of the meeting at the 56th IETF which were
posted to the list, we (the chairs) solicited for volunteers to help
write the next documents [including this one].  And those participating
(Paul, Juergen, Jeff) were the respondents, with respect to the
info/data model document.

> If this is the case, then shouldn't
> the call be open to more people?

If you have input on the info/data model at this point, you're welcome
to post it to the list perhaps in reply in context to the con-call
minutes that covered the major topics with respect to the document.

When they produce the next revision you're welcome to comment on it as
well.

My intention in posting minutes of the discussion amongst document
editors was to let the WG group know what's going on.  No thanks necessary. ;^)

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  Thu Jun  5 13:20:12 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06993
	for <ipfix-archive@lists.ietf.org>; Thu, 5 Jun 2003 13:20:11 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Ny9K-00044x-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 05 Jun 2003 12:03:38 -0500
Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Ny9J-00044p-00
	for ipfix@net.doit.wisc.edu; Thu, 05 Jun 2003 12:03:37 -0500
Date: Thu, 5 Jun 2003 12:03:37 -0500
From: Dave Plonka <plonka@doit.wisc.edu>
To: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] info/data model status, con-call minutes
Message-ID: <20030605120337.A14791@doit.wisc.edu>
Reply-To: plonka@doit.wisc.edu
References: <5C8959A16A71B449AE793CF52FBBED66153E8D@ptah.newyork.qosient.com> <5C8959A16A71B449AE793CF52FBBED6607A5EE@ptah.newyork.qosient.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A5EE@ptah.newyork.qosient.com>; from carter@qosient.com on Thu, Jun 05, 2003 at 12:55:23PM -0400
X-Organization: University of Wisconsin-Madison, DoIT Network Services
X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL)
X-URL: http://net.doit.wisc.edu/~plonka/
X-VMS-Error: %SYSTEM-W-NOTINSEC, virtual address not in global section
X-Shakespearean-Insult: Thou villainous idle-headed harpy
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

On Thu, Jun 05, 2003 at 12:55:23PM -0400, Carter Bullard wrote:
<snip>
>    The problem with piggybacking new material onto
> an existing draft, without having the new material
> independently reviewed, is that there is the impression
> that the new material has had the same level of
> review as the older draft.  It also introduces the
> potential problem that in order to achieve some progress
> on the base document, the review of the new material
> will not be as critical or as stringent, for the sake
> of progress.
>
>    It would be nice if the attributes were developed
> in a separate draft, so that we can get it right, with
> the full intention of merging it into the existing
> document when we have consensus.  And it will be much
> easier to track the changes in a separate draft than
> in an older document that will also have changes that are
> independent of the attribute work.

OK, thanks for pointing that out.  As mentioned in the minutes I
posted, we should review RFC3444 ("On the Difference between
Information Models and Data Models") http://www.ietf.org/rfc/rfc3444.txt,
to determine if its more properly called an Information Model.  If you've
read it, or would like to, please let us know what you think.

If we change the name then we'll be back to a "-00" revision.  This is
really just an administrative bit, so don't anyone get hung up on the
Internet Draft's name - we'll figure it out.

I think its fair to say that the info/data model draft will need
as significant a review as a "-00" regardless of its name, since it
has been some time since that document had been touched.

Thanks,
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  Thu Jun  5 13:22:12 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07143
	for <ipfix-archive@lists.ietf.org>; Thu, 5 Jun 2003 13:22:11 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Ny1R-0003rE-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 05 Jun 2003 11:55:29 -0500
Received: from relay.pair.com ([209.68.1.20])
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 19Ny1P-0003r7-00
	for ipfix@net.doit.wisc.edu; Thu, 05 Jun 2003 11:55:27 -0500
Received: (qmail 32259 invoked from network); 5 Jun 2003 16:55:26 -0000
Received: from 207-237-237-207.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.237.207)
  by relay.pair.com with SMTP; 5 Jun 2003 16:55:26 -0000
X-pair-Authenticated: 207.237.237.207
Received: from sphynx (sphynx [192.168.0.64])
	by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h55GtR704025;
	Thu, 5 Jun 2003 12:55:27 -0400
From: "Carter Bullard" <carter@qosient.com>
To: <plonka@doit.wisc.edu>, <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] info/data model status, con-call minutes
Date: Thu, 5 Jun 2003 12:55:23 -0400
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A5EE@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.4510
Importance: Normal
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED66153E8D@ptah.newyork.qosient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Hey Dave,
   No problem, and of course thanks for doing such
an admirable job ;o)  I was just interested in the
process since I wasn't at the last meeting.  Anything
that streamlines the process is fine with me as long
as the quality is still good.

   The problem with piggybacking new material onto
an existing draft, without having the new material
independently reviewed, is that there is the impression
that the new material has had the same level of
review as the older draft.  It also introduces the
potential problem that in order to achieve some progress
on the base document, the review of the new material
will not be as critical or as stringent, for the sake
of progress.

   It would be nice if the attributes were developed
in a separate draft, so that we can get it right, with
the full intention of merging it into the existing
document when we have consensus.  And it will be much
easier to track the changes in a separate draft than
in an older document that will also have changes that are
independent of the attribute work.

   Just some thoughts, and I apologize for not being
able to attend.

Carter



> -----Original Message-----
> From: majordomo listserver 
> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Dave Plonka
> Sent: Thursday, June 05, 2003 12:34 PM
> To: ipfix@net.doit.wisc.edu
> Cc: Carter Bullard
> Subject: Re: [ipfix] info/data model status, con-call minutes
> 
> 
> 
> Hi Carter,
> 
> On Thu, Jun 05, 2003 at 12:20:20PM -0400, Carter Bullard wrote:
> > Editors generally edit existing documents, but it
> > sounds to me that you guys are writing new material
> > that has not yet been presented as a draft nor discussed
> > on the list.
> 
> It is an existing document, although it has expired.  It is the one
> KC and Paul Calato edited, the latest revision mirrored is here:
> 
   http://ipfix.doit.wisc.edu/data/draft-ietf-ipfix-data-00.txt

although ther is apparently a "-01" revision that has been lost track of.

As noted in the minutes of the meeting at the 56th IETF which were
posted to the list, we (the chairs) solicited for volunteers to help
write the next documents [including this one].  And those participating
(Paul, Juergen, Jeff) were the respondents, with respect to the
info/data model document.

> If this is the case, then shouldn't
> the call be open to more people?

If you have input on the info/data model at this point, you're welcome
to post it to the list perhaps in reply in context to the con-call
minutes that covered the major topics with respect to the document.

When they produce the next revision you're welcome to comment on it as
well.

My intention in posting minutes of the discussion amongst document
editors was to let the WG group know what's going on.  No thanks necessary.
;^)

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/


From majordomo@mil.doit.wisc.edu  Tue Jun 10 17:31:05 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18897
	for <ipfix-archive@lists.ietf.org>; Tue, 10 Jun 2003 17:31:05 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19PqLU-0002gh-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 10 Jun 2003 16:07:56 -0500
Received: from halt-in.cisco.com ([171.70.144.185])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19PqLT-0002ga-00
	for ipfix@net.doit.wisc.edu; Tue, 10 Jun 2003 16:07:55 -0500
Received: from cisco.com (171.71.163.13)
  by halt-in.cisco.com with ESMTP; 10 Jun 2003 14:08:12 -0800
Received: from cisco.com (dhcp-171-71-204-251.cisco.com [171.71.204.251])
	by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AHC93461;
	Tue, 10 Jun 2003 13:55:47 -0700 (PDT)
Message-ID: <3EE64432.3D6E2E8C@cisco.com>
Date: Tue, 10 Jun 2003 13:48:50 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [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] Middle box functions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


Can someone restate what  "middle-box functions" need to be done
by an IPFIX device?

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  Tue Jun 10 20:17:29 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23833
	for <ipfix-archive@lists.ietf.org>; Tue, 10 Jun 2003 20:17:29 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Pt5w-00079k-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 10 Jun 2003 19:04:04 -0500
Received: from halt-in.cisco.com ([171.70.144.185])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Pt5v-00079e-00
	for ipfix@net.doit.wisc.edu; Tue, 10 Jun 2003 19:04:03 -0500
Received: from cisco.com (171.71.163.13)
  by halt-in.cisco.com with ESMTP; 10 Jun 2003 17:04:03 -0800
Received: from cisco.com (dhcp-171-71-204-251.cisco.com [171.71.204.251])
	by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AHD15756;
	Tue, 10 Jun 2003 17:09:33 -0700 (PDT)
Message-ID: <3EE6719D.CE5ED0FA@cisco.com>
Date: Tue, 10 Jun 2003 17:02:38 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tal Givoly <givoly@xacct.com>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Middle box functions
References: <DLEIIIOHMNPJPNMKGEFDIEFGDKAA.givoly@xacct.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Sorry for the brevity.
There is a line in the architecture spec. on the function of Observation Domain.

"Perform appropriate middle-box functions to translate the
flow information."

1. This is not a function of the Observation Domain as it is a logical block
rather
than a functional block.
2.It would be moslty a IPFIX protocol function in which case I would like to put

in some more words. So if someone can provide a few sentences stating what is
intended by "Middle box functions" I can put it into the arch. spec.

Thanks
Ganesh

Tal Givoly wrote:

> Ganesh,
>
> I personally didn't quite understand the question, perhaps you would like to
> elaborate or provide some more context for us to clarify/respond.
>
> Thanks,
>
> Tal
>
> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Ganesh Sadasivan
> Sent: Tuesday, June 10, 2003 1:49 PM
> To: ipfix@net.doit.wisc.edu
> Subject: [ipfix] Middle box functions
>
> Can someone restate what  "middle-box functions" need to be done
> by an IPFIX device?
>
> 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/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 10 20:54:43 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24830
	for <ipfix-archive@lists.ietf.org>; Tue, 10 Jun 2003 20:54:43 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Pteq-0000L0-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 10 Jun 2003 19:40:08 -0500
Received: from smtp-out.sprintlabs.com ([208.30.172.76])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Ptep-0000Ks-00
	for ipfix@net.doit.wisc.edu; Tue, 10 Jun 2003 19:40:07 -0500
Received: from mailman.sprintlabs.com (mx.sprintlabs.com [199.2.53.192])
	by smtp-out.sprintlabs.com (Postfix) with ESMTP
	id 5B4CBB80F5; Tue, 10 Jun 2003 17:40:34 -0700 (PDT)
Received: by mailman.sprintlabs.com with Internet Mail Service (5.5.2656.59)
	id <K9G4SN0N>; Tue, 10 Jun 2003 17:40:06 -0700
Received: from IPTOSH1 (ip-tosh-1.sprintlabs.com [199.2.53.185]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id K9G4SN0L; Tue, 10 Jun 2003 17:40:01 -0700
From: Supratik Bhattacharyya <Supratik@sprintlabs.com>
To: ipfix@net.doit.wisc.edu, psamp@ops.ietf.org, ippm@ietf.org
Cc: "'Randy Bush'" <randy@psg.com>, "'Bert Wijnen'" <bwijnen@lucent.com>,
        "'bill fenner'" <fenner@research.att.com>, dmm@1-4-5.net,
        Christophe Diot <christophe.diot@intel.com>,
        Gianluca Iannaccone <gianluca@sprintlabs.com>,
        "Nina A. Taft" <Nina@sprintlabs.com>,
        Supratik Bhattacharyya <Supratik@sprintlabs.com>
Subject: [ipfix] BOF proposal
Date: Tue, 10 Jun 2003 17:40:01 -0700
Message-ID: <7F2A07FEA8F5624E887FE460E6E0527DCDF515@PDAWB06C.ad.sprint.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.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

[Apologies if you receive multiple copies of this email.]

Greetings,

We have written a short internet draft on issues and concerns in
deploying monitoring infrastructure in ISP networks. The goal of this
document is to open a discussion on whether there should be a BOF to
address these at the next IETF (Vienna, July 2003). We welcome
comments/inputs from everyone.

The draft can be found at:

http://www.ietf.org/internet-drafts/draft-bhattacharyya-monitoring-deplo
yment-00.txt


Thanks and regards,

Supratik Bhattacharyya
Gianluca Iannaccone
Christophe Diot

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 11 07:56:45 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04012
	for <ipfix-archive@lists.ietf.org>; Wed, 11 Jun 2003 07:56:45 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Q3p0-0002lT-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 06:31:18 -0500
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 19Q3oz-0002lK-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 06:31:17 -0500
Received: from cisco.com (dhcp-peg3-vl30-144-254-7-108.cisco.com [144.254.7.108])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h5BBV7p09622;
	Wed, 11 Jun 2003 13:31:07 +0200 (CEST)
Message-ID: <3EE712F9.7000004@cisco.com>
Date: Wed, 11 Jun 2003 13:31:05 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
CC: Mark Fullmer <maf@eng.oar.net>, calato@riverstonenet.com,
        ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] drawing the line between protocol and data model document
References: <1D3D2C371FCBD947A7897FABBD3533A566BA84@xsun01.ptp.hp.com> <3EB13485.3FA365D7@riverstonenet.com> <20030501162116.B33173@net.ohio-state.edu> <3EDCB48D.40207@cisco.com>
In-Reply-To: <3EDCB48D.40207@cisco.com>
Content-Type: multipart/alternative;
 boundary="------------080901090401080405090207"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.
--------------080901090401080405090207
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

> Mark,
>
>>On Thu, May 01, 2003 at 10:51:49AM -0400, calato@riverstonenet.com wrote:
>>
>><snip>
>>
>>  
>>
>>>The richness of the protocol encoding specification is another
>>>matter. The protocol would reference each element in the data
>>>model and define exaclty how that element is encoded. In the above 
>>>example, the protocol is free to encode that as an unsigned byte 
>>>if the value is < 256. 
>>>    
>>>
>>
>>The ramifications of doing this with a template based system are a bit
>>ugly.  Consider a flow with just 2 counters -- octets, packets.
>>Each could have a 1 to 8 byte encoding.  That's a potential of 64
>>different templates for representing 1 type of flow.
>>
>>This (at first glance) looks like it adds considerable cycles to the
>>encode / decode process to save a few bytes in the transport.
>>
>>The current v9 spec appears to allow this, but only for IN_BYTES and
>>IN_PKTS.
>>
>>  
>>
>>>                                          counter with length
>>>   IN_BYTES                 1       N     N x 8 bits for bytes
>>>                                          associated with an IP Flow
>>>    
>>>
>>
>>Is this true?  Benoit?
>>  
>>
> I'm trying to catch up with my IPIFX emails; I know I'm late on this 
> thread, which seems to have reached consensus as far as I can tell, 
> but as this is a direct question to me, let me answer.
> Actually, there are:
> BYTES            1             4             field type for the 32 bit 
> bytes counter
> BYTES_64      23           8             field type for the 64 bit 
> bytes counter

Let me reply to my own email because, after speaking to different 
people, I have to correct what I said.
We actually do:

                                          Incoming counter with length
   IN_BYTES                 1       N     N x 8 bits for bytes
                                          associated with an IP Flow

                                          Incoming counter with length
   IN_PKTS		    2       N     N x 8 bits for packets
                                          associated with an IP Flow

And no BYTES_64 is defined.

Regards, Benoit.


>
>
> So the draft that you refer to needs a quick update.
>
> Regards, Benoit
>
>
>
>>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/
>>  
>>
>


--------------080901090401080405090207
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Dear all,<br>
<blockquote type="cite" cite="mid3EDCB48D.40207@cisco.com">
  <meta http-equiv="Content-Type" content="text/html;">
  <title></title>
Mark,
  <blockquote type="cite"
 cite="mid20030501162116.B33173@net.ohio-state.edu">
    <pre wrap="">On Thu, May 01, 2003 at 10:51:49AM -0400, <a
 class="moz-txt-link-abbreviated" href="mailto:calato@riverstonenet.com">calato@riverstonenet.com</a> wrote:

&lt;snip&gt;

  </pre>
    <blockquote type="cite">
      <pre wrap="">The richness of the protocol encoding specification is another
matter. The protocol would reference each element in the data
model and define exaclty how that element is encoded. In the above 
example, the protocol is free to encode that as an unsigned byte 
if the value is &lt; 256. 
    </pre>
    </blockquote>
    <pre wrap=""><!---->
The ramifications of doing this with a template based system are a bit
ugly.  Consider a flow with just 2 counters -- octets, packets.
Each could have a 1 to 8 byte encoding.  That's a potential of 64
different templates for representing 1 type of flow.

This (at first glance) looks like it adds considerable cycles to the
encode / decode process to save a few bytes in the transport.

The current v9 spec appears to allow this, but only for IN_BYTES and
IN_PKTS.

  </pre>
    <blockquote type="cite">
      <pre wrap="">                                          counter with length
   IN_BYTES                 1       N     N x 8 bits for bytes
                                          associated with an IP Flow
    </pre>
    </blockquote>
    <pre wrap=""><!---->
Is this true?  Benoit?
  </pre>
  </blockquote>
I'm trying to catch up with my IPIFX emails; I know I'm late on this
thread, which seems to have reached consensus as far as I can tell, but
as this is a direct question to me, let me answer.<br>
Actually, there are:<br>
BYTES&nbsp; &nbsp;&nbsp;  &nbsp;&nbsp;  &nbsp; &nbsp;  1 &nbsp;&nbsp;  &nbsp;&nbsp;  &nbsp;&nbsp;  &nbsp;&nbsp;  4 &nbsp;&nbsp;  &nbsp;&nbsp;  &nbsp;&nbsp;  &nbsp;&nbsp; field type for
the 32 bit bytes counter<br>
BYTES_64&nbsp;&nbsp;  &nbsp;&nbsp;  23&nbsp;&nbsp;  &nbsp;&nbsp;  &nbsp;&nbsp;&nbsp;&nbsp;  8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; field type for the 64 bit
bytes counter</blockquote>
Let me reply to my own email because, after speaking to different
people, I have to correct what I said.<br>
We actually do:<br>
<pre wrap="">                                          Incoming counter with length
   IN_BYTES                 1       N     N x 8 bits for bytes
                                          associated with an IP Flow

                                          Incoming counter with length
   IN_PKTS		    2       N     N x 8 bits for packets
                                          associated with an IP Flow

And no BYTES_64 is defined.

Regards, Benoit.

<span lang="EN-US"
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;;"><span style=""></span><span
 style=""></span></span></pre>
<blockquote type="cite" cite="mid3EDCB48D.40207@cisco.com"><br>
  <br>
So the draft that you refer to needs a quick update.<br>
<!--[endif]--><o:idmap v:ext="edit" data="3"></o:idmap><br>
Regards, Benoit<br>
  <br>
  <br>
  <br>
  <blockquote type="cite"
 cite="mid20030501162116.B33173@net.ohio-state.edu">
    <pre wrap="">
mark

--
Help        <a class="moz-txt-link-freetext"
 href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help<a
 class="moz-txt-link-rfc2396E"
 href="inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay">" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"</a>unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext"
 href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>
  </pre>
  </blockquote>
  <br>
</blockquote>
<br>
</body>
</html>

--------------080901090401080405090207--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 11 07:59:26 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04077
	for <ipfix-archive@lists.ietf.org>; Wed, 11 Jun 2003 07:59:25 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Q3tC-0002vZ-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 06:35:38 -0500
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 19Q3tA-0002vU-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 06:35:36 -0500
Received: from cisco.com (dhcp-peg3-vl30-144-254-7-108.cisco.com [144.254.7.108])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h5BBZJp13577;
	Wed, 11 Jun 2003 13:35:19 +0200 (CEST)
Message-ID: <3EE713F5.3060605@cisco.com>
Date: Wed, 11 Jun 2003 13:35:17 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sebastian Zander <zander@fokus.fraunhofer.de>
CC: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] extensibility of the ipfix protocol
References: <1D3D2C371FCBD947A7897FABBD3533A566BB3F@xsun01.ptp.hp.com> <3ECC2CC1.8090900@fokus.fraunhofer.de>
In-Reply-To: <3ECC2CC1.8090900@fokus.fraunhofer.de>
Content-Type: multipart/alternative;
 boundary="------------090305010507020403080801"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.
--------------090305010507020403080801
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jeff and Sebastian,

> Jeff,
>
> comments below
>
> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>
>> Sebastian,
>>
>>   I'd agree that making the extensibility model more explicit is 
>> desireable.
>>     I'm still unclear on when or why one would extend information 
>> into the
>> header
>> vs. extending the data template sent itself.  I view the Option 
>> template as
>> flagging "pseudo-flow records" which have a set of attributes which 
>> carry
>> information other than actual flow details, e.g. configuration info or
>> counters.
>>
>>   But isn't the combination of having Extensible Flow Records (for 
>> "real"
>> data) and Extensible Option Records (for "other" data) sufficient to 
>> move
>> any form of data the exporter wants to export?
>>
>>   I guess this is what Mark was saying.  So I'd agree to that.
>
>
> I also agree
>
>>   I would see the same "Information Model" and extension model being 
>> used
>> for both Flow Record and Options.
>>
>>
>>   So to clarify, the header is fixed.  There is a distinction between 
>> flow
>> records and "other" data transmitted by the exporter.  And a common way
>> of defining how attributes which appear in either flow or option records
>> will be used.
>>
>>   I'm not sure on why the "Scope" options should be treated differently
>> than any other attribute which may appear in an Option Record 
>> (Section 6.1)
>> in NFv9 specification.  Seems like things would be simpler and just as
>> effective if there were just a "Scope" attribute which could appear in
>> Option records.  In this case an Options template would be identical
>> to a Flow Template except it would have a FlowSet id of 1 vs. 0.
>>
>>   Does that work? 
>
Jeff,
Yes it would work.
One argument for treating the scope differently is that the scope must 
be applied to all options data records.
And the Scope is an important data type. If you don't know about it, you 
can't apply the "action" that is associated with the options flow record.
For example: if the scope is the line card X and the sampling rate Y and 
if the collector doesn't know abouth the scope for the line card, the 
exporter doesn't know that the number of bytes should be multipled by 
the sampling rate.
Ok, that would be almost the same for an unknow data types in the flow 
data record, but that one could just be reported, without taking an "action"

>>
>
> I must admit that i don't 100% understand how scope is supposed to work.
> The example in 10.4 and 10.5 seems somewhat flawed. The draft says 
> there are
> N scope fields and N option fields. Must the number of scope fields be 
> equal
> to the number of option fields? If yes this seems to waste lots of 
> space if the
> scope does not change (and it is not the case in the example). If not 
> (probably
> the authors meant M and N) the question is how to map the scope fields 
> to the
> options fields when there is more than 1 scope field (seems impossibe)? 

Sebastian, you are right that the intention is to have M and N. This has 
been corrected in the latest draft.
How to map the scope fields to the options fields when there is more 
than 1 scope field?
The scope can be limited further by listing multiple scopes which all 
have to match at the same time.

>
>
> Making scope another attribute sounds somewhat good. However has scope 
> some
> kind of grouping functionality 

Yes exactly. See the previous answer to Jeff

> or must it explicitly appear before each option?
> Can scopes be combined such as e.g. this option is per interface vs. 
> this option
> is per template per interface?

Exactly.

Regards, Benoit.

> I think my questions are about grouping because
> scope seems to have some kind of grouping function...
>
> Cheers,
>
> Sebastian
>
>>
>> Regards,
>>
>>   Jeff Meyer
>>
>> -----Original Message-----
>> From: Sebastian Zander [mailto:zander@fokus.fraunhofer.de]
>> Sent: Wednesday, May 21, 2003 5:19 PM
>> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>> Cc: ipfix@net.doit.wisc.edu
>> Subject: Re: [ipfix] extensibility of the ipfix protocol
>>
>>
>> Jeff,
>>
>> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>>
>>> Sebastian,
>>>
>>>  One of the issues of talking about extensibility in the generic 
>>> sense is
>>> that it creates the temptation to specify generality without any 
>>> driving
>>> use case.  "Someone may want to ..." seems like a slippery slope in
>>
>>
>> bounding
>>
>>> requirements.
>>>
>>>  In particular the case (1) extending fields in the header sounds
>>
>>
>> dubious.
>>
>>>  Since IPFIX is about getting flow records from the exporter to the
>>> collector,
>>> what is the purpose of allowing arbitrary header extensions?
>>
>>
>>
>> The purpose is to send information per packet which is associated to or
>> necessary for using the rest of the information contained in the 
>> packet. For
>> me its pretty obvious that you need such an extension mechanism. And 
>> as Mark
>> pointed out this is already supported by the use of option templates.
>>
>> netflow certainly meets the extensibility reqs but the netflow drafts do
>> *not*
>> a good job IMO in explaining its extensibility compared to e.g. what
>> Diameter
>> does. Instead of letting the reader guess the ipfix draft should have 
>> more
>> verbage.
>>
>>
>>>   In case (2), I'd certainly recommend option (b), making an explicit
>>> separation of namespaces (in this case integer values) by using unique
>>> vendor ids as independent "namespace authorities" seems like common 
>>> sense.
>>> SNMP's been doing this for years, and Diameter is also following this
>>> convention as you point out.
>>>
>>>  As for case (3), my understanding is that explicit type information in
>>> the payload/template itself did not achieve consensus.   This does mean
>>> that the numeric id (and optional vendorId) needs some concept of type,
>>> in a supporting document.  Having each attribute specify its type by
>>> reference to a type space defined in the base IPFIX Information Model
>>> is the way to go here (in my opinion).
>>
>>
>>
>> Yeah, but the protocol draft must be aligned somehow to the information
>> model draft e.g. where are the types defined, where is the encoding
>> defined...
>>
>> Cheers,
>>
>> Sebastian
>>
>>
>>>  When a vendor extends the set of attributes, chosing a well defined
>>> type would be preferred to inventing a new type.  If the vendor cannot
>>> resist the overwhelming temptation to create new types, it can be 
>>> defined in their own information model.
>>>
>>>
>>> Regards,
>>>
>>>  Jeff Meyer
>>>
>>> -----Original Message-----
>>> From: Sebastian Zander [mailto:zander@fokus.fraunhofer.de]
>>> Sent: Tuesday, May 06, 2003 6:55 PM
>>> To: ipfix@net.doit.wisc.edu
>>> Subject: [ipfix] extensibility of the ipfix protocol
>>>
>>>
>>> Hi,
>>>
>>> although extensibility is mandatory by the requirements there hasn't
>>> been a lot discussion on how to do it and the chosen candidate protocol
>>> doesn't say much about extensibility. So here are my thoughts about
>>> extensibility.
>>>
>>> The protocol specification must define how the protocol can be 
>>> extended.
>>>
>>> I see the following (but there may be more) ways of extending the
>>> protocol:
>>>
>>> 1. Extending the fixed packet header
>>> This would allow to add new header fields without changing the
>>> protocol specification.
>>>
>>> A bit (X) could be stolen from version to indicate the presence of
>>> extension header(s). Extension header(s) follow the fixed header if
>>> X=1. Extension header(s) consists of type, length and value.
>>>
>>> 2. Extending the attribute/field space
>>> This is certainly needed. It could be done at least in two ways:
>>> a) A flat number space where numbers are specified in extension
>>>    RFCs and registered by IANA. A nice thing would a dynamic
>>>    space where numbers are not defined by IANA but could be negotiated
>>>    out of band (see payload type in the RTP specification). Such a
>>>    space could also be used as safe playground.
>>> b) A number space which is defined in extension RFCs (IANA) and the
>>>    possibility of using vendor specific attributes by having an 
>>> optional
>>>    vendor ID field in the template specification. The vendor ID would
>>>    be IANA assigned but the vendor then could use its private field ID
>>>    space (see the Diameter Base protocol specification). Adds more
>>>    complexity and overhead to the protocol but could be very useful
>>>    when the protocol becomes widely adopted and a lot of extensions
>>>    are done.
>>>
>>> 3. Extending the type space (if there are types at all)
>>> Probably there won't be much need to extent this because the protocol
>>> specification could do a good job of specifying all the basic types.
>>> If this really needs to be extended it would be probably done with a
>>> revised protocol specification.
>>>
>>> Comments? Opinions?
>>>
>>> Cheers,
>>>
>>> Sebastian
>>>
>>
>>
>>
>
>


--------------090305010507020403080801
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Hi Jeff and Sebastian,<br>
<blockquote type="cite" cite="mid3ECC2CC1.8090900@fokus.fraunhofer.de">Jeff,<br>
  <br>
comments below <br>
  <br>
MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: <br>
  <blockquote type="cite">Sebastian, <br>
    <br>
&nbsp; I'd agree that making the extensibility model more explicit is
desireable. <br>
&nbsp; &nbsp; I'm still unclear on when or why one would extend information into
the <br>
header <br>
vs. extending the data template sent itself.&nbsp; I view the Option
template as <br>
flagging "pseudo-flow records" which have a set of attributes which
carry <br>
information other than actual flow details, e.g. configuration info or <br>
counters. <br>
    <br>
&nbsp; But isn't the combination of having Extensible Flow Records (for
"real" <br>
data) and Extensible Option Records (for "other" data) sufficient to
move <br>
any form of data the exporter wants to export? <br>
    <br>
&nbsp; I guess this is what Mark was saying.&nbsp; So I'd agree to that. <br>
  </blockquote>
  <br>
I also agree <br>
  <br>
  <blockquote type="cite">&nbsp; I would see the same "Information Model"
and extension model being used <br>
for both Flow Record and Options. <br>
    <br>
    <br>
&nbsp; So to clarify, the header is fixed.&nbsp; There is a distinction between
flow <br>
records and "other" data transmitted by the exporter.&nbsp; And a common way <br>
of defining how attributes which appear in either flow or option
records <br>
will be used. <br>
    <br>
&nbsp; I'm not sure on why the "Scope" options should be treated differently <br>
than any other attribute which may appear in an Option Record (Section
6.1) <br>
in NFv9 specification.&nbsp; Seems like things would be simpler and just as <br>
effective if there were just a "Scope" attribute which could appear in <br>
Option records.&nbsp; In this case an Options template would be identical <br>
to a Flow Template except it would have a FlowSet id of 1 vs. 0. <br>
    <br>
&nbsp; Does that work? </blockquote>
</blockquote>
Jeff,<br>
Yes it would work.<br>
One argument for treating the scope differently is that the scope must
be applied to all options data records.<br>
And the Scope is an important data type. If you don't know about it,
you can't apply the "action" that is associated with the options flow
record.<br>
For example: if the scope is the line card X and the sampling rate Y
and if the collector doesn't know abouth the scope for the line card,
the exporter doesn't know that the number of bytes should be multipled
by the sampling rate.<br>
Ok, that would be almost the same for an unknow data types in the flow
data record, but that one could just be reported, without taking an
"action"<br>
<br>
<blockquote type="cite" cite="mid3ECC2CC1.8090900@fokus.fraunhofer.de">
  <blockquote type="cite"><br>
  </blockquote>
  <br>
I must admit that i don't 100% understand how scope is supposed to
work. <br>
The example in 10.4 and 10.5 seems somewhat flawed. The draft says
there are <br>
N scope fields and N option fields. Must the number of scope fields be
equal <br>
to the number of option fields? If yes this seems to waste lots of
space if the <br>
scope does not change (and it is not the case in the example). If not
(probably <br>
the authors meant M and N) the question is how to map the scope fields
to the <br>
options fields when there is more than 1 scope field (seems impossibe)? </blockquote>
Sebastian, you are right that the intention is to have M and N. This
has been corrected in the latest draft.<br>
How to map the scope fields to the options fields when there is more
than 1 scope field?<br>
The scope can be limited further by listing multiple scopes which all
have to match at the same time.<span lang="EN-US"
 style="font-size: 12pt; font-family: &quot;Courier New&quot;;"></span><br>
<blockquote type="cite" cite="mid3ECC2CC1.8090900@fokus.fraunhofer.de"><br>
  <br>
Making scope another attribute sounds somewhat good. However has scope
some <br>
kind of grouping functionality </blockquote>
Yes exactly. See the previous answer to Jeff<br>
<blockquote type="cite" cite="mid3ECC2CC1.8090900@fokus.fraunhofer.de">or
must it explicitly appear before each option? <br>
Can scopes be combined such as e.g. this option is per interface vs.
this option <br>
is per template per interface?</blockquote>
Exactly.<br>
<br>
Regards, Benoit.<br>
<blockquote type="cite" cite="mid3ECC2CC1.8090900@fokus.fraunhofer.de">
I think my questions are about grouping because <br>
scope seems to have some kind of grouping function... <br>
  <br>
Cheers, <br>
  <br>
Sebastian <br>
  <br>
  <blockquote type="cite"> <br>
Regards, <br>
    <br>
&nbsp; Jeff Meyer <br>
    <br>
-----Original Message----- <br>
From: Sebastian Zander [<a class="moz-txt-link-freetext" href="mailto:zander@fokus.fraunhofer.de">mailto:zander@fokus.fraunhofer.de</a>] <br>
Sent: Wednesday, May 21, 2003 5:19 PM <br>
To: MEYER,JEFFREY D (HP-Cupertino,ex1) <br>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a> <br>
Subject: Re: [ipfix] extensibility of the ipfix protocol <br>
    <br>
    <br>
Jeff, <br>
    <br>
MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: <br>
    <br>
    <blockquote type="cite">Sebastian, <br>
      <br>
&nbsp;One of the issues of talking about extensibility in the generic sense
is <br>
that it creates the temptation to specify generality without any
driving <br>
use case.&nbsp; "Someone may want to ..." seems like a slippery slope in <br>
    </blockquote>
    <br>
bounding <br>
    <br>
    <blockquote type="cite">requirements. <br>
      <br>
&nbsp;In particular the case (1) extending fields in the header sounds <br>
    </blockquote>
    <br>
dubious. <br>
    <br>
    <blockquote type="cite">&nbsp;Since IPFIX is about getting flow records
from the exporter to the <br>
collector, <br>
what is the purpose of allowing arbitrary header extensions? <br>
    </blockquote>
    <br>
    <br>
The purpose is to send information per packet which is associated to or <br>
necessary for using the rest of the information contained in the
packet. For <br>
me its pretty obvious that you need such an extension mechanism. And as
Mark <br>
pointed out this is already supported by the use of option templates. <br>
    <br>
netflow certainly meets the extensibility reqs but the netflow drafts
do <br>
*not* <br>
a good job IMO in explaining its extensibility compared to e.g. what <br>
Diameter <br>
does. Instead of letting the reader guess the ipfix draft should have
more <br>
verbage. <br>
    <br>
    <br>
    <blockquote type="cite">&nbsp; In case (2), I'd certainly recommend
option (b), making an explicit <br>
separation of namespaces (in this case integer values) by using unique <br>
vendor ids as independent "namespace authorities" seems like common
sense. <br>
SNMP's been doing this for years, and Diameter is also following this <br>
convention as you point out. <br>
      <br>
&nbsp;As for case (3), my understanding is that explicit type information in <br>
the payload/template itself did not achieve consensus.&nbsp;&nbsp; This does mean <br>
that the numeric id (and optional vendorId) needs some concept of type, <br>
in a supporting document.&nbsp; Having each attribute specify its type by <br>
reference to a type space defined in the base IPFIX Information Model <br>
is the way to go here (in my opinion). <br>
    </blockquote>
    <br>
    <br>
Yeah, but the protocol draft must be aligned somehow to the information <br>
model draft e.g. where are the types defined, where is the encoding <br>
defined... <br>
    <br>
Cheers, <br>
    <br>
Sebastian <br>
    <br>
    <br>
    <blockquote type="cite">&nbsp;When a vendor extends the set of
attributes, chosing a well defined <br>
type would be preferred to inventing a new type.&nbsp; If the vendor cannot <br>
resist the overwhelming temptation to create new types, it can be
defined in their own information model. <br>
      <br>
      <br>
Regards, <br>
      <br>
&nbsp;Jeff Meyer <br>
      <br>
-----Original Message----- <br>
From: Sebastian Zander [<a class="moz-txt-link-freetext" href="mailto:zander@fokus.fraunhofer.de">mailto:zander@fokus.fraunhofer.de</a>] <br>
Sent: Tuesday, May 06, 2003 6:55 PM <br>
To: <a class="moz-txt-link-abbreviated" href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a> <br>
Subject: [ipfix] extensibility of the ipfix protocol <br>
      <br>
      <br>
Hi, <br>
      <br>
although extensibility is mandatory by the requirements there hasn't <br>
been a lot discussion on how to do it and the chosen candidate protocol <br>
doesn't say much about extensibility. So here are my thoughts about <br>
extensibility. <br>
      <br>
The protocol specification must define how the protocol can be
extended. <br>
      <br>
I see the following (but there may be more) ways of extending the <br>
protocol: <br>
      <br>
1. Extending the fixed packet header <br>
This would allow to add new header fields without changing the <br>
protocol specification. <br>
      <br>
A bit (X) could be stolen from version to indicate the presence of <br>
extension header(s). Extension header(s) follow the fixed header if <br>
X=1. Extension header(s) consists of type, length and value. <br>
      <br>
2. Extending the attribute/field space <br>
This is certainly needed. It could be done at least in two ways: <br>
a) A flat number space where numbers are specified in extension <br>
&nbsp;&nbsp; RFCs and registered by IANA. A nice thing would a dynamic <br>
&nbsp;&nbsp; space where numbers are not defined by IANA but could be negotiated <br>
&nbsp;&nbsp; out of band (see payload type in the RTP specification). Such a <br>
&nbsp;&nbsp; space could also be used as safe playground. <br>
b) A number space which is defined in extension RFCs (IANA) and the <br>
&nbsp;&nbsp; possibility of using vendor specific attributes by having an
optional <br>
&nbsp;&nbsp; vendor ID field in the template specification. The vendor ID would <br>
&nbsp;&nbsp; be IANA assigned but the vendor then could use its private field ID <br>
&nbsp;&nbsp; space (see the Diameter Base protocol specification). Adds more <br>
&nbsp;&nbsp; complexity and overhead to the protocol but could be very useful <br>
&nbsp;&nbsp; when the protocol becomes widely adopted and a lot of extensions <br>
&nbsp;&nbsp; are done. <br>
      <br>
3. Extending the type space (if there are types at all) <br>
Probably there won't be much need to extent this because the protocol <br>
specification could do a good job of specifying all the basic types. <br>
If this really needs to be extended it would be probably done with a <br>
revised protocol specification. <br>
      <br>
Comments? Opinions? <br>
      <br>
Cheers, <br>
      <br>
Sebastian <br>
      <br>
    </blockquote>
    <br>
    <br>
    <br>
  </blockquote>
  <br>
  <br>
</blockquote>
<br>
</body>
</html>

--------------090305010507020403080801--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 11 07:59:48 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04103
	for <ipfix-archive@lists.ietf.org>; Wed, 11 Jun 2003 07:59:48 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Q3o3-0002jE-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 06:30:19 -0500
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Q3o2-0002j6-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 06:30:18 -0500
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 11 Jun 2003 13:29:18 +0100
Received: from bru-cse-222.cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5BBSHh4016405
	for <ipfix@net.doit.wisc.edu>; Wed, 11 Jun 2003 13:28:17 +0200 (MET DST)
Received: (from bclaise@localhost)
	by bru-cse-222.cisco.com (8.11.7+Sun/8.11.6) id h5BBUG913755;
	Wed, 11 Jun 2003 13:30:16 +0200 (CEST)
Date: Wed, 11 Jun 2003 13:30:16 +0200 (CEST)
From: Benoit Claise <bclaise@cisco.com>
Message-Id: <200306111130.h5BBUG913755@bru-cse-222.cisco.com>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] draft-claise-netflow-version9-02.txt
X-Sun-Charset: US-ASCII
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Dear all, 

The draft-claise-netflow-version9-02.txt has been produced and is on its way to be posted by the IETF.
As some excerpts could be reused in the protocol and information IPFIX drafts, and knowing the deadlines that IPFIX faces, you can find a copy in the mean time by following the procedure below.


Regards, Benoit.


The file names is:
* draft-claise-netflow-version9-02.txt (NetFlow version 9 latest draft)

To get these files, please do the following...

   1. With a Netscape or Internet Explorer web browser open
      the following URL:
        http://www.cisco.com/pcgi-bin/specialaccess.cgi
   2. At the 'Special Access Code' prompt, enter in TLGMQSEV
   3. Click on the 'Execute' button.  This will bring you
      to a web page listing your files for pickup.
   4. Select each file listed.  Each selection will take
      you to the Software Download web page; click on any
      Site listed to download your file to your local disk.
 

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 11 13:01:32 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17337
	for <ipfix-archive@lists.ietf.org>; Wed, 11 Jun 2003 13:01:32 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Q8jH-0002GO-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 11:45:43 -0500
Received: from atlrel9.hp.com ([156.153.255.214])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Q8jF-0002GJ-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 11:45:41 -0500
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel9.hp.com (Postfix) with ESMTP
	id 495F21C00C3D; Wed, 11 Jun 2003 12:45:41 -0400 (EDT)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP
	id 0FBC61C000AC; Wed, 11 Jun 2003 12:45:41 -0400 (EDT)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <MPLQ819V>; Wed, 11 Jun 2003 12:45:40 -0400
Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960067@xsun01.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Benoit Claise'" <bclaise@cisco.com>,
        Sebastian Zander <zander@fokus.fraunhofer.de>
Cc: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] extensibility of the ipfix protocol
Date: Wed, 11 Jun 2003 12:45:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C33038.E2AFA6D0"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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_01C33038.E2AFA6D0
Content-Type: text/plain;
	charset="iso-8859-1"

Benoit,
 
  So it sounds like "scope" is more or less a way to pack multiple discrete
records into a single template.  This means that templates are no longer
necessarily in first normal form as some attributes may repeat.
 
  In general, I still think this is a lot of complexity to address a use
case which could be addressed with other mechanisms already present in NFv9,
i.e. treat all attributes as equals from the protocol perspective, only have
one template model, distinguish between "option records" and "flow records".
 
  Since I believe that the information transfer you describe can be
accomplished with fewer moving parts in the protocol, and since the
"simplicity" of netflow was cited as a key reason for its selection, can we
make this simplification?
 
Regards,
 
  Jeff Meyer

-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Wednesday, June 11, 2003 4:35 AM
To: Sebastian Zander
Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] extensibility of the ipfix protocol


Hi Jeff and Sebastian,


Jeff,

comments below 

MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: 


Sebastian, 

  I'd agree that making the extensibility model more explicit is desireable.

    I'm still unclear on when or why one would extend information into the 
header 
vs. extending the data template sent itself.  I view the Option template as 
flagging "pseudo-flow records" which have a set of attributes which carry 
information other than actual flow details, e.g. configuration info or 
counters. 

  But isn't the combination of having Extensible Flow Records (for "real" 
data) and Extensible Option Records (for "other" data) sufficient to move 
any form of data the exporter wants to export? 

  I guess this is what Mark was saying.  So I'd agree to that. 



I also agree 



  I would see the same "Information Model" and extension model being used 
for both Flow Record and Options. 


  So to clarify, the header is fixed.  There is a distinction between flow 
records and "other" data transmitted by the exporter.  And a common way 
of defining how attributes which appear in either flow or option records 
will be used. 

  I'm not sure on why the "Scope" options should be treated differently 
than any other attribute which may appear in an Option Record (Section 6.1) 
in NFv9 specification.  Seems like things would be simpler and just as 
effective if there were just a "Scope" attribute which could appear in 
Option records.  In this case an Options template would be identical 
to a Flow Template except it would have a FlowSet id of 1 vs. 0. 

  Does that work? 

Jeff,
Yes it would work.
One argument for treating the scope differently is that the scope must be
applied to all options data records.
And the Scope is an important data type. If you don't know about it, you
can't apply the "action" that is associated with the options flow record.
For example: if the scope is the line card X and the sampling rate Y and if
the collector doesn't know abouth the scope for the line card, the exporter
doesn't know that the number of bytes should be multipled by the sampling
rate.
Ok, that would be almost the same for an unknow data types in the flow data
record, but that one could just be reported, without taking an "action"





I must admit that i don't 100% understand how scope is supposed to work. 
The example in 10.4 and 10.5 seems somewhat flawed. The draft says there are

N scope fields and N option fields. Must the number of scope fields be equal

to the number of option fields? If yes this seems to waste lots of space if
the 
scope does not change (and it is not the case in the example). If not
(probably 
the authors meant M and N) the question is how to map the scope fields to
the 
options fields when there is more than 1 scope field (seems impossibe)? 

Sebastian, you are right that the intention is to have M and N. This has
been corrected in the latest draft.
How to map the scope fields to the options fields when there is more than 1
scope field?
The scope can be limited further by listing multiple scopes which all have
to match at the same time.




Making scope another attribute sounds somewhat good. However has scope some 
kind of grouping functionality 

Yes exactly. See the previous answer to Jeff


or must it explicitly appear before each option? 
Can scopes be combined such as e.g. this option is per interface vs. this
option 
is per template per interface?

Exactly.

Regards, Benoit.


I think my questions are about grouping because 
scope seems to have some kind of grouping function... 

Cheers, 

Sebastian 




Regards, 

  Jeff Meyer 

-----Original Message----- 
From: Sebastian Zander [ mailto:zander@fokus.fraunhofer.de
<mailto:zander@fokus.fraunhofer.de> ] 
Sent: Wednesday, May 21, 2003 5:19 PM 
To: MEYER,JEFFREY D (HP-Cupertino,ex1) 
Cc: ipfix@net.doit.wisc.edu <mailto:ipfix@net.doit.wisc.edu>  
Subject: Re: [ipfix] extensibility of the ipfix protocol 


Jeff, 

MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: 



Sebastian, 

 One of the issues of talking about extensibility in the generic sense is 
that it creates the temptation to specify generality without any driving 
use case.  "Someone may want to ..." seems like a slippery slope in 



bounding 



requirements. 

 In particular the case (1) extending fields in the header sounds 



dubious. 



 Since IPFIX is about getting flow records from the exporter to the 
collector, 
what is the purpose of allowing arbitrary header extensions? 




The purpose is to send information per packet which is associated to or 
necessary for using the rest of the information contained in the packet. For

me its pretty obvious that you need such an extension mechanism. And as Mark

pointed out this is already supported by the use of option templates. 

netflow certainly meets the extensibility reqs but the netflow drafts do 
*not* 
a good job IMO in explaining its extensibility compared to e.g. what 
Diameter 
does. Instead of letting the reader guess the ipfix draft should have more 
verbage. 




  In case (2), I'd certainly recommend option (b), making an explicit 
separation of namespaces (in this case integer values) by using unique 
vendor ids as independent "namespace authorities" seems like common sense. 
SNMP's been doing this for years, and Diameter is also following this 
convention as you point out. 

 As for case (3), my understanding is that explicit type information in 
the payload/template itself did not achieve consensus.   This does mean 
that the numeric id (and optional vendorId) needs some concept of type, 
in a supporting document.  Having each attribute specify its type by 
reference to a type space defined in the base IPFIX Information Model 
is the way to go here (in my opinion). 




Yeah, but the protocol draft must be aligned somehow to the information 
model draft e.g. where are the types defined, where is the encoding 
defined... 

Cheers, 

Sebastian 




 When a vendor extends the set of attributes, chosing a well defined 
type would be preferred to inventing a new type.  If the vendor cannot 
resist the overwhelming temptation to create new types, it can be defined in
their own information model. 


Regards, 

 Jeff Meyer 

-----Original Message----- 
From: Sebastian Zander [ mailto:zander@fokus.fraunhofer.de
<mailto:zander@fokus.fraunhofer.de> ] 
Sent: Tuesday, May 06, 2003 6:55 PM 
To: ipfix@net.doit.wisc.edu <mailto:ipfix@net.doit.wisc.edu>  
Subject: [ipfix] extensibility of the ipfix protocol 


Hi, 

although extensibility is mandatory by the requirements there hasn't 
been a lot discussion on how to do it and the chosen candidate protocol 
doesn't say much about extensibility. So here are my thoughts about 
extensibility. 

The protocol specification must define how the protocol can be extended. 

I see the following (but there may be more) ways of extending the 
protocol: 

1. Extending the fixed packet header 
This would allow to add new header fields without changing the 
protocol specification. 

A bit (X) could be stolen from version to indicate the presence of 
extension header(s). Extension header(s) follow the fixed header if 
X=1. Extension header(s) consists of type, length and value. 

2. Extending the attribute/field space 
This is certainly needed. It could be done at least in two ways: 
a) A flat number space where numbers are specified in extension 
   RFCs and registered by IANA. A nice thing would a dynamic 
   space where numbers are not defined by IANA but could be negotiated 
   out of band (see payload type in the RTP specification). Such a 
   space could also be used as safe playground. 
b) A number space which is defined in extension RFCs (IANA) and the 
   possibility of using vendor specific attributes by having an optional 
   vendor ID field in the template specification. The vendor ID would 
   be IANA assigned but the vendor then could use its private field ID 
   space (see the Diameter Base protocol specification). Adds more 
   complexity and overhead to the protocol but could be very useful 
   when the protocol becomes widely adopted and a lot of extensions 
   are done. 

3. Extending the type space (if there are types at all) 
Probably there won't be much need to extent this because the protocol 
specification could do a good job of specifying all the basic types. 
If this really needs to be extended it would be probably done with a 
revised protocol specification. 

Comments? Opinions? 

Cheers, 

Sebastian 










------_=_NextPart_001_01C33038.E2AFA6D0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE></TITLE>

<META content="MSHTML 5.50.4915.500" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=453254416-11062003><FONT face=Arial color=#0000ff 
size=2>Benoit,</FONT></SPAN></DIV>
<DIV><SPAN class=453254416-11062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=453254416-11062003><FONT face=Arial color=#0000ff size=2>&nbsp; 
So it sounds like "scope" is more or less a way to pack multiple discrete 
records into a single template.&nbsp; This means that templates are no longer 
necessarily in first normal form as some attributes may 
repeat.</FONT></SPAN></DIV>
<DIV><SPAN class=453254416-11062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=453254416-11062003><FONT face=Arial color=#0000ff size=2>&nbsp; 
In general, I still think this is a lot of complexity to address a use case 
which could be addressed with other mechanisms already present in NFv9, i.e. 
treat all attributes as equals from the protocol perspective, only have one 
template model, distinguish between "option records" and "flow 
records".</FONT></SPAN></DIV>
<DIV><SPAN class=453254416-11062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=453254416-11062003><FONT face=Arial color=#0000ff size=2>&nbsp; 
Since I believe that the information transfer you describe can be accomplished 
with fewer moving parts in the protocol, and since the "simplicity" of netflow 
was cited as a key reason for its selection, can we make this 
simplification?</FONT></SPAN></DIV>
<DIV><SPAN class=453254416-11062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=453254416-11062003><FONT face=Arial color=#0000ff 
size=2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=453254416-11062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=453254416-11062003><FONT face=Arial color=#0000ff size=2>&nbsp; 
Jeff Meyer</FONT></SPAN></DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Benoit Claise 
  [mailto:bclaise@cisco.com]<BR><B>Sent:</B> Wednesday, June 11, 2003 4:35 
  AM<BR><B>To:</B> Sebastian Zander<BR><B>Cc:</B> MEYER,JEFFREY D 
  (HP-Cupertino,ex1); ipfix@net.doit.wisc.edu<BR><B>Subject:</B> Re: [ipfix] 
  extensibility of the ipfix protocol<BR><BR></FONT></DIV>Hi Jeff and 
  Sebastian,<BR>
  <BLOCKQUOTE cite="mid3ECC2CC1.8090900@fokus.fraunhofer.de" 
    type="cite">Jeff,<BR><BR>comments below <BR><BR>MEYER,JEFFREY D 
    (HP-Cupertino,ex1) wrote: <BR>
    <BLOCKQUOTE type="cite">Sebastian, <BR><BR>&nbsp; I'd agree that making 
      the extensibility model more explicit is desireable. <BR>&nbsp; &nbsp; I'm 
      still unclear on when or why one would extend information into the 
      <BR>header <BR>vs. extending the data template sent itself.&nbsp; I view 
      the Option template as <BR>flagging "pseudo-flow records" which have a set 
      of attributes which carry <BR>information other than actual flow details, 
      e.g. configuration info or <BR>counters. <BR><BR>&nbsp; But isn't the 
      combination of having Extensible Flow Records (for "real" <BR>data) and 
      Extensible Option Records (for "other" data) sufficient to move <BR>any 
      form of data the exporter wants to export? <BR><BR>&nbsp; I guess this is 
      what Mark was saying.&nbsp; So I'd agree to that. <BR></BLOCKQUOTE><BR>I 
    also agree <BR><BR>
    <BLOCKQUOTE type="cite">&nbsp; I would see the same "Information Model" 
      and extension model being used <BR>for both Flow Record and Options. 
      <BR><BR><BR>&nbsp; So to clarify, the header is fixed.&nbsp; There is a 
      distinction between flow <BR>records and "other" data transmitted by the 
      exporter.&nbsp; And a common way <BR>of defining how attributes which 
      appear in either flow or option records <BR>will be used. <BR><BR>&nbsp; 
      I'm not sure on why the "Scope" options should be treated differently 
      <BR>than any other attribute which may appear in an Option Record (Section 
      6.1) <BR>in NFv9 specification.&nbsp; Seems like things would be simpler 
      and just as <BR>effective if there were just a "Scope" attribute which 
      could appear in <BR>Option records.&nbsp; In this case an Options template 
      would be identical <BR>to a Flow Template except it would have a FlowSet 
      id of 1 vs. 0. <BR><BR>&nbsp; Does that work? 
  </BLOCKQUOTE></BLOCKQUOTE>Jeff,<BR>Yes it would work.<BR>One argument for 
  treating the scope differently is that the scope must be applied to all 
  options data records.<BR>And the Scope is an important data type. If you don't 
  know about it, you can't apply the "action" that is associated with the 
  options flow record.<BR>For example: if the scope is the line card X and the 
  sampling rate Y and if the collector doesn't know abouth the scope for the 
  line card, the exporter doesn't know that the number of bytes should be 
  multipled by the sampling rate.<BR>Ok, that would be almost the same for an 
  unknow data types in the flow data record, but that one could just be 
  reported, without taking an "action"<BR><BR>
  <BLOCKQUOTE cite="mid3ECC2CC1.8090900@fokus.fraunhofer.de" type="cite">
    <BLOCKQUOTE type="cite"><BR></BLOCKQUOTE><BR>I must admit that i don't 100% 
    understand how scope is supposed to work. <BR>The example in 10.4 and 10.5 
    seems somewhat flawed. The draft says there are <BR>N scope fields and N 
    option fields. Must the number of scope fields be equal <BR>to the number of 
    option fields? If yes this seems to waste lots of space if the <BR>scope 
    does not change (and it is not the case in the example). If not (probably 
    <BR>the authors meant M and N) the question is how to map the scope fields 
    to the <BR>options fields when there is more than 1 scope field (seems 
    impossibe)? </BLOCKQUOTE>Sebastian, you are right that the intention is to 
  have M and N. This has been corrected in the latest draft.<BR>How to map the 
  scope fields to the options fields when there is more than 1 scope 
  field?<BR>The scope can be limited further by listing multiple scopes which 
  all have to match at the same time.<SPAN lang=EN-US 
  style="FONT-SIZE: 12pt; FONT-FAMILY: 'Courier New'"></SPAN><BR>
  <BLOCKQUOTE cite="mid3ECC2CC1.8090900@fokus.fraunhofer.de" 
    type="cite"><BR><BR>Making scope another attribute sounds somewhat good. 
    However has scope some <BR>kind of grouping functionality </BLOCKQUOTE>Yes 
  exactly. See the previous answer to Jeff<BR>
  <BLOCKQUOTE cite="mid3ECC2CC1.8090900@fokus.fraunhofer.de" type="cite">or 
    must it explicitly appear before each option? <BR>Can scopes be combined 
    such as e.g. this option is per interface vs. this option <BR>is per 
    template per interface?</BLOCKQUOTE>Exactly.<BR><BR>Regards, Benoit.<BR>
  <BLOCKQUOTE cite="mid3ECC2CC1.8090900@fokus.fraunhofer.de" type="cite">I 
    think my questions are about grouping because <BR>scope seems to have some 
    kind of grouping function... <BR><BR>Cheers, <BR><BR>Sebastian <BR><BR>
    <BLOCKQUOTE type="cite"><BR>Regards, <BR><BR>&nbsp; Jeff Meyer 
      <BR><BR>-----Original Message----- <BR>From: Sebastian Zander [<A 
      class=moz-txt-link-freetext 
      href="mailto:zander@fokus.fraunhofer.de">mailto:zander@fokus.fraunhofer.de</A>] 
      <BR>Sent: Wednesday, May 21, 2003 5:19 PM <BR>To: MEYER,JEFFREY D 
      (HP-Cupertino,ex1) <BR>Cc: <A class=moz-txt-link-abbreviated 
      href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</A> 
      <BR>Subject: Re: [ipfix] extensibility of the ipfix protocol 
      <BR><BR><BR>Jeff, <BR><BR>MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: 
      <BR><BR>
      <BLOCKQUOTE type="cite">Sebastian, <BR><BR>&nbsp;One of the issues of 
        talking about extensibility in the generic sense is <BR>that it creates 
        the temptation to specify generality without any driving <BR>use 
        case.&nbsp; "Someone may want to ..." seems like a slippery slope in 
      <BR></BLOCKQUOTE><BR>bounding <BR><BR>
      <BLOCKQUOTE type="cite">requirements. <BR><BR>&nbsp;In particular the 
        case (1) extending fields in the header sounds 
      <BR></BLOCKQUOTE><BR>dubious. <BR><BR>
      <BLOCKQUOTE type="cite">&nbsp;Since IPFIX is about getting flow records 
        from the exporter to the <BR>collector, <BR>what is the purpose of 
        allowing arbitrary header extensions? <BR></BLOCKQUOTE><BR><BR>The purpose 
      is to send information per packet which is associated to or <BR>necessary 
      for using the rest of the information contained in the packet. For <BR>me 
      its pretty obvious that you need such an extension mechanism. And as Mark 
      <BR>pointed out this is already supported by the use of option templates. 
      <BR><BR>netflow certainly meets the extensibility reqs but the netflow 
      drafts do <BR>*not* <BR>a good job IMO in explaining its extensibility 
      compared to e.g. what <BR>Diameter <BR>does. Instead of letting the reader 
      guess the ipfix draft should have more <BR>verbage. <BR><BR><BR>
      <BLOCKQUOTE type="cite">&nbsp; In case (2), I'd certainly recommend 
        option (b), making an explicit <BR>separation of namespaces (in this 
        case integer values) by using unique <BR>vendor ids as independent 
        "namespace authorities" seems like common sense. <BR>SNMP's been doing 
        this for years, and Diameter is also following this <BR>convention as 
        you point out. <BR><BR>&nbsp;As for case (3), my understanding is that 
        explicit type information in <BR>the payload/template itself did not 
        achieve consensus.&nbsp;&nbsp; This does mean <BR>that the numeric id 
        (and optional vendorId) needs some concept of type, <BR>in a supporting 
        document.&nbsp; Having each attribute specify its type by <BR>reference 
        to a type space defined in the base IPFIX Information Model <BR>is the 
        way to go here (in my opinion). <BR></BLOCKQUOTE><BR><BR>Yeah, but the 
      protocol draft must be aligned somehow to the information <BR>model draft 
      e.g. where are the types defined, where is the encoding <BR>defined... 
      <BR><BR>Cheers, <BR><BR>Sebastian <BR><BR><BR>
      <BLOCKQUOTE type="cite">&nbsp;When a vendor extends the set of 
        attributes, chosing a well defined <BR>type would be preferred to 
        inventing a new type.&nbsp; If the vendor cannot <BR>resist the 
        overwhelming temptation to create new types, it can be defined in their 
        own information model. <BR><BR><BR>Regards, <BR><BR>&nbsp;Jeff Meyer 
        <BR><BR>-----Original Message----- <BR>From: Sebastian Zander [<A 
        class=moz-txt-link-freetext 
        href="mailto:zander@fokus.fraunhofer.de">mailto:zander@fokus.fraunhofer.de</A>] 
        <BR>Sent: Tuesday, May 06, 2003 6:55 PM <BR>To: <A 
        class=moz-txt-link-abbreviated 
        href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</A> 
        <BR>Subject: [ipfix] extensibility of the ipfix protocol <BR><BR><BR>Hi, 
        <BR><BR>although extensibility is mandatory by the requirements there 
        hasn't <BR>been a lot discussion on how to do it and the chosen 
        candidate protocol <BR>doesn't say much about extensibility. So here are 
        my thoughts about <BR>extensibility. <BR><BR>The protocol specification 
        must define how the protocol can be extended. <BR><BR>I see the 
        following (but there may be more) ways of extending the <BR>protocol: 
        <BR><BR>1. Extending the fixed packet header <BR>This would allow to add 
        new header fields without changing the <BR>protocol specification. 
        <BR><BR>A bit (X) could be stolen from version to indicate the presence 
        of <BR>extension header(s). Extension header(s) follow the fixed header 
        if <BR>X=1. Extension header(s) consists of type, length and value. 
        <BR><BR>2. Extending the attribute/field space <BR>This is certainly 
        needed. It could be done at least in two ways: <BR>a) A flat number 
        space where numbers are specified in extension <BR>&nbsp;&nbsp; RFCs and 
        registered by IANA. A nice thing would a dynamic <BR>&nbsp;&nbsp; space 
        where numbers are not defined by IANA but could be negotiated 
        <BR>&nbsp;&nbsp; out of band (see payload type in the RTP 
        specification). Such a <BR>&nbsp;&nbsp; space could also be used as safe 
        playground. <BR>b) A number space which is defined in extension RFCs 
        (IANA) and the <BR>&nbsp;&nbsp; possibility of using vendor specific 
        attributes by having an optional <BR>&nbsp;&nbsp; vendor ID field in the 
        template specification. The vendor ID would <BR>&nbsp;&nbsp; be IANA 
        assigned but the vendor then could use its private field ID 
        <BR>&nbsp;&nbsp; space (see the Diameter Base protocol specification). 
        Adds more <BR>&nbsp;&nbsp; complexity and overhead to the protocol but 
        could be very useful <BR>&nbsp;&nbsp; when the protocol becomes widely 
        adopted and a lot of extensions <BR>&nbsp;&nbsp; are done. <BR><BR>3. 
        Extending the type space (if there are types at all) <BR>Probably there 
        won't be much need to extent this because the protocol <BR>specification 
        could do a good job of specifying all the basic types. <BR>If this 
        really needs to be extended it would be probably done with a <BR>revised 
        protocol specification. <BR><BR>Comments? Opinions? <BR><BR>Cheers, 
        <BR><BR>Sebastian 
  <BR><BR></BLOCKQUOTE><BR><BR><BR></BLOCKQUOTE><BR><BR></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C33038.E2AFA6D0--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 11 13:07:29 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17456
	for <ipfix-archive@lists.ietf.org>; Wed, 11 Jun 2003 13:07:29 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Q8pc-0002PD-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 11:52:16 -0500
Received: from atlrel7.hp.com ([156.153.255.213])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Q8pb-0002P2-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 11:52:15 -0500
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel7.hp.com (Postfix) with ESMTP
	id DBA7E1C00745; Wed, 11 Jun 2003 12:52:14 -0400 (EDT)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP
	id D32BB1C009C8; Wed, 11 Jun 2003 12:52:14 -0400 (EDT)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <MPLQ8GC3>; Wed, 11 Jun 2003 12:52:14 -0400
Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960068@xsun01.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Benoit Claise'" <bclaise@cisco.com>, ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] draft-claise-netflow-version9-02.txt
Date: Wed, 11 Jun 2003 12:52:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Benoit,

  Are the set of information items defined in -02 the complete set as 
you see it or do you think there are additional information items?
 
  I know Paul Calato is independently tracking the set down, but wanted
to understand your perspective.

  For the field identifier range (Section 8), I imagine resuing the id's 
already defined as part of NFv9 would make sense.  If new information
items are identified, is the number 79 the starting point?

  Also has the IANA disposition of these identifiers been discussed.  E.g.
will control of these be passed over to IANA as part of the process
of this WG's output?


Regards,

  Jeff Meyer

> -----Original Message-----
> From: Benoit Claise [mailto:bclaise@cisco.com]
> Sent: Wednesday, June 11, 2003 4:30 AM
> To: ipfix@net.doit.wisc.edu
> Subject: [ipfix] draft-claise-netflow-version9-02.txt
> 
> 
> Dear all, 
> 
> The draft-claise-netflow-version9-02.txt has been produced 
> and is on its way to be posted by the IETF.
> As some excerpts could be reused in the protocol and 
> information IPFIX drafts, and knowing the deadlines that 
> IPFIX faces, you can find a copy in the mean time by 
> following the procedure below.
> 
> 
> Regards, Benoit.
> 
> 
> The file names is:
> * draft-claise-netflow-version9-02.txt (NetFlow version 9 
> latest draft)
> 
> To get these files, please do the following...
> 
>    1. With a Netscape or Internet Explorer web browser open
>       the following URL:
>         http://www.cisco.com/pcgi-bin/specialaccess.cgi
>    2. At the 'Special Access Code' prompt, enter in TLGMQSEV
>    3. Click on the 'Execute' button.  This will bring you
>       to a web page listing your files for pickup.
>    4. Select each file listed.  Each selection will take
>       you to the Software Download web page; click on any
>       Site listed to download your file to your local disk.
>  
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
> 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 Jun 11 13:11:13 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17576
	for <ipfix-archive@lists.ietf.org>; Wed, 11 Jun 2003 13:11:12 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Q8xN-0002lk-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 12:00:17 -0500
Received: from atlrel8.hp.com ([156.153.255.206])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Q8xM-0002le-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 12:00:16 -0500
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel8.hp.com (Postfix) with ESMTP
	id 48AD61C01136; Wed, 11 Jun 2003 13:00:16 -0400 (EDT)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP
	id 146781C000AC; Wed, 11 Jun 2003 13:00:16 -0400 (EDT)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <MPLQ8HR1>; Wed, 11 Jun 2003 13:00:15 -0400
Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960069@xsun01.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Benoit Claise'" <bclaise@cisco.com>
Cc: Mark Fullmer <maf@eng.oar.net>, calato@riverstonenet.com,
        ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] drawing the line between protocol and data model docu
	ment
Date: Wed, 11 Jun 2003 13:00:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3303A.ECB5F510"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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_01C3303A.ECB5F510
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,
 
  From a practical perspective, simply saying that a field is numeric and
may be encoded as 1 or 100 bytes seems like it puts an unnecessary and
unjustified burden on the collector, or any other app which might want to
handle this data.
 
  Is there some particular reason why saying a specific information item,
e.g. numBytes, is a 32-bit integer or a 64-bit integer is considered
undesireable.  It certainly seems like the developer of a consuming
application would benefit from knowing how to target variables in their
application for given information items.  I guess one could assume that
everything will fit in a 64-bit integer and code your app that way, but
again, this seems like an unnecessary burden for unclear gains.
 
  I don't think anything needs to change in the protocol.  Simply a more
constrained approach to dealing with numeric fields with explicit types.
 
Regards,

  Jeff Meyer

-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Wednesday, June 11, 2003 4:31 AM
To: Benoit Claise
Cc: Mark Fullmer; calato@riverstonenet.com; ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] drawing the line between protocol and data model
document


Dear all,


Mark, 

On Thu, May 01, 2003 at 10:51:49AM -0400,  calato@riverstonenet.com
<mailto:calato@riverstonenet.com>  wrote:



<snip>



  

The richness of the protocol encoding specification is another

matter. The protocol would reference each element in the data

model and define exaclty how that element is encoded. In the above 

example, the protocol is free to encode that as an unsigned byte 

if the value is < 256. 

    



The ramifications of doing this with a template based system are a bit

ugly.  Consider a flow with just 2 counters -- octets, packets.

Each could have a 1 to 8 byte encoding.  That's a potential of 64

different templates for representing 1 type of flow.



This (at first glance) looks like it adds considerable cycles to the

encode / decode process to save a few bytes in the transport.



The current v9 spec appears to allow this, but only for IN_BYTES and

IN_PKTS.



  

                                          counter with length

   IN_BYTES                 1       N     N x 8 bits for bytes

                                          associated with an IP Flow

    



Is this true?  Benoit?

  

I'm trying to catch up with my IPIFX emails; I know I'm late on this thread,
which seems to have reached consensus as far as I can tell, but as this is a
direct question to me, let me answer.
Actually, there are:
BYTES            1             4             field type for the 32 bit bytes
counter
BYTES_64      23           8             field type for the 64 bit bytes
counter

Let me reply to my own email because, after speaking to different people, I
have to correct what I said.
We actually do:

                                          Incoming counter with length

   IN_BYTES                 1       N     N x 8 bits for bytes

                                          associated with an IP Flow



                                          Incoming counter with length

   IN_PKTS		    2       N     N x 8 bits for packets

                                          associated with an IP Flow



And no BYTES_64 is defined.



Regards, Benoit.







So the draft that you refer to needs a quick update.
<!--[endif]-->
Regards, Benoit





mark



--

Help         mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say "help " in message body
<inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay> 

Unsubscribe mailto:majordomo@net.doit.wisc.edu and say

"unsubscribe ipfix" in message body

Archive      http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/> 

  




------_=_NextPart_001_01C3303A.ECB5F510
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE></TITLE>

<META content=3D"MSHTML 5.50.4915.500" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
From a practical perspective, simply saying that a field is numeric and =
may be=20
encoded as 1 or 100 bytes seems like it puts an unnecessary and =
unjustified=20
burden on the collector, or any other app which might want to handle =
this=20
data.</FONT></SPAN></DIV>
<DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
Is there some particular reason why saying a specific information item, =
e.g.=20
numBytes, is a 32-bit integer or a 64-bit integer is considered=20
undesireable.&nbsp; It certainly seems like the developer of a =
consuming=20
application would benefit from knowing how to target variables in their =

application for given information items.&nbsp; I guess one could assume =
that=20
everything will fit in a 64-bit integer and code your app that way, but =
again,=20
this seems like an unnecessary burden for unclear =
gains.</FONT></SPAN></DIV>
<DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
I don't think anything needs to change in the protocol.&nbsp; Simply a =
more=20
constrained approach to dealing with numeric fields with explicit=20
types.</FONT></SPAN></DIV>
<DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2><BR>&nbsp; Jeff Meyer</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Benoit Claise=20
  [mailto:bclaise@cisco.com]<BR><B>Sent:</B> Wednesday, June 11, 2003 =
4:31=20
  AM<BR><B>To:</B> Benoit Claise<BR><B>Cc:</B> Mark Fullmer;=20
  calato@riverstonenet.com; ipfix@net.doit.wisc.edu<BR><B>Subject:</B> =
Re:=20
  [ipfix] drawing the line between protocol and data model=20
  document<BR><BR></FONT></DIV>Dear all,<BR>
  <BLOCKQUOTE cite=3D"mid3EDCB48D.40207@cisco.com" type=3D"cite">Mark,=20
    <BLOCKQUOTE cite=3D"mid20030501162116.B33173@net.ohio-state.edu" =
type=3D"cite"><PRE wrap=3D"">On Thu, May 01, 2003 at 10:51:49AM -0400, =
<A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:calato@riverstonenet.com">calato@riverstonenet.com</A> =
wrote:

&lt;snip&gt;

  </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">The richness of the =
protocol encoding specification is another
matter. The protocol would reference each element in the data
model and define exaclty how that element is encoded. In the above=20
example, the protocol is free to encode that as an unsigned byte=20
if the value is &lt; 256.=20
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
The ramifications of doing this with a template based system are a bit
ugly.  Consider a flow with just 2 counters -- octets, packets.
Each could have a 1 to 8 byte encoding.  That's a potential of 64
different templates for representing 1 type of flow.

This (at first glance) looks like it adds considerable cycles to the
encode / decode process to save a few bytes in the transport.

The current v9 spec appears to allow this, but only for IN_BYTES and
IN_PKTS.

  </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">                         =
                 counter with length
   IN_BYTES                 1       N     N x 8 bits for bytes
                                          associated with an IP Flow
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
Is this true?  Benoit?
  </PRE></BLOCKQUOTE>I'm trying to catch up with my IPIFX emails; I =
know I'm=20
    late on this thread, which seems to have reached consensus as far =
as I can=20
    tell, but as this is a direct question to me, let me =
answer.<BR>Actually,=20
    there are:<BR>BYTES&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp; &nbsp; 1 =

    &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; 4 &nbsp;&nbsp;=20
    &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; field type for the 32 bit =
bytes=20
    counter<BR>BYTES_64&nbsp;&nbsp; &nbsp;&nbsp; 23&nbsp;&nbsp; =
&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp;&nbsp;=20
    =
8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
    field type for the 64 bit bytes counter</BLOCKQUOTE>Let me reply to =
my own=20
  email because, after speaking to different people, I have to correct =
what I=20
  said.<BR>We actually do:<BR><PRE wrap=3D"">                           =
               Incoming counter with length
   IN_BYTES                 1       N     N x 8 bits for bytes
                                          associated with an IP Flow

                                          Incoming counter with length
   IN_PKTS		    2       N     N x 8 bits for packets
                                          associated with an IP Flow

And no BYTES_64 is defined.

Regards, Benoit.

<SPAN lang=3DEN-US style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman'"><SPAN></SPAN><SPAN></SPAN></SPAN></PRE>
  <BLOCKQUOTE cite=3D"mid3EDCB48D.40207@cisco.com" =
type=3D"cite"><BR><BR>So the=20
    draft that you refer to needs a quick=20
    update.<BR>&lt;!--[endif]--&gt;<O:IDMAP data=3D"3"=20
    v:ext=3D"edit"></O:IDMAP><BR>Regards, Benoit<BR><BR><BR><BR>
    <BLOCKQUOTE cite=3D"mid20030501162116.B33173@net.ohio-state.edu" =
type=3D"cite"><PRE wrap=3D"">mark

--
Help        <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wi=
sc.edu</A> and say "help<A class=3Dmoz-txt-link-rfc2396E =
href=3D"inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay=
">" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"</A>unsubscribe ipfix" in message body
Archive     <A class=3Dmoz-txt-link-freetext =
href=3D"http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/=
archive/</A>
  </PRE></BLOCKQUOTE><BR></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3303A.ECB5F510--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 11 13:28:32 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18290
	for <ipfix-archive@lists.ietf.org>; Wed, 11 Jun 2003 13:28:32 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Q99e-00035V-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 12:12:58 -0500
Received: from atlrel7.hp.com ([156.153.255.213])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Q99d-00035M-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 12:12:57 -0500
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel7.hp.com (Postfix) with ESMTP
	id 0F2871C006B4; Wed, 11 Jun 2003 13:12:57 -0400 (EDT)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP
	id EEF341C000A9; Wed, 11 Jun 2003 13:12:56 -0400 (EDT)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <MPLQ8J5Z>; Wed, 11 Jun 2003 13:12:56 -0400
Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50296006A@xsun01.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ganesh Sadasivan'" <gsadasiv@cisco.com>, Tal Givoly <givoly@xacct.com>
Cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] Middle box functions
Date: Wed, 11 Jun 2003 13:12:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Ganesh,

  I think I see your point.  In rereading the Middlebox specification:

    http://www.ietf.org/rfc/rfc3234.txt

  They provide a list (in section 2) of 22 different functional activities
of various
categories of middleboxes.

  They also provide a list (in section 2.23) of functions which are NOT
considered to be middlebox activities.

  In this non-middlebox list they have the following text:

     Wiretaps and snoopers in general - if they are working correctly,
     they have no impact on traffic, so do not require analysis.

  In effect they are saying a Middlebox by definition ALTERS the default
flow of IP packets.  It would seem to me that IPFIX does not specify any
such behavior.  The observer is simply watching, not altering the flow.

  Hence, I would recommend REMOVING references to Middleboxes.


Regards,

  Jeff Meyer


> -----Original Message-----
> From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
> Sent: Tuesday, June 10, 2003 5:03 PM
> To: Tal Givoly
> Cc: ipfix@net.doit.wisc.edu
> Subject: Re: [ipfix] Middle box functions
> 
> 
> Sorry for the brevity.
> There is a line in the architecture spec. on the function of 
> Observation Domain.
> 
> "Perform appropriate middle-box functions to translate the
> flow information."
> 
> 1. This is not a function of the Observation Domain as it is 
> a logical block
> rather
> than a functional block.
> 2.It would be moslty a IPFIX protocol function in which case 
> I would like to put
> 
> in some more words. So if someone can provide a few sentences 
> stating what is
> intended by "Middle box functions" I can put it into the arch. spec.
> 
> Thanks
> Ganesh
> 
> Tal Givoly wrote:
> 
> > Ganesh,
> >
> > I personally didn't quite understand the question, perhaps 
> you would like to
> > elaborate or provide some more context for us to clarify/respond.
> >
> > Thanks,
> >
> > Tal
> >
> > -----Original Message-----
> > From: majordomo listserver 
> [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> > Of Ganesh Sadasivan
> > Sent: Tuesday, June 10, 2003 1:49 PM
> > To: ipfix@net.doit.wisc.edu
> > Subject: [ipfix] Middle box functions
> >
> > Can someone restate what  "middle-box functions" need to be done
> > by an IPFIX device?
> >
> > 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/
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
> 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 Jun 11 15:07:05 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22346
	for <ipfix-archive@lists.ietf.org>; Wed, 11 Jun 2003 15:07:04 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QAnj-0005z6-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 13:58:27 -0500
Received: from halt-in.cisco.com ([171.70.144.185])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19QAnh-0005z0-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 13:58:25 -0500
Received: from cisco.com (171.71.163.13)
  by halt-in.cisco.com with ESMTP; 11 Jun 2003 11:58:20 -0800
Received: from cisco.com (dhcp-171-71-204-251.cisco.com [171.71.204.251])
	by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AHE05233;
	Wed, 11 Jun 2003 12:04:59 -0700 (PDT)
Message-ID: <3EE77BCC.FF358FB8@cisco.com>
Date: Wed, 11 Jun 2003 11:58:20 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [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] IPFIX-ARCH : Functional flow diagram.
References: <1D3D2C371FCBD947A7897FABBD3533A50296006A@xsun01.ptp.hp.com>
Content-Type: multipart/alternative;
 boundary="------------5334ED95245CEA69A6807872"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


--------------5334ED95245CEA69A6807872
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,
   I want to add this figure into the architecture spec. Please go through
this send
   send any comments/corrections.

                    Packet(s) coming into Observation Point(s)
                    |                                   |
                    |                                   |
                    v                                   v
  +-----------------+-------------------------+   +-----+------+
  |           Metering Process on an          |   |            |
  |              Observation Point            |   |            |
  |  packet header capturing                  |   |            |
  |         |                                 |   | Metering   |
  |    timestamping                           |   | Process    |
  |         |                                 |   | on an      |
  |         v                                 |   | Observation|
  |  +------+                                 |   | Point      |
  |  |      |                                 |   |            |
  |  |   sampling Si (1:1 in case of no       |   |            |
  |  |      |          sampling)              |   |            |
  |  | classifying Fi (NULL when No criteria) |   |            |
  |  |      |                                 |   |            |
  |  +------+                                 |   |            |
  |         |                                 |   |            |
  +---------+---------------------------------+   +-----+------+
            |                                           |
          Flows (identified by observation domain)    Flows
            +----...                                    +--------+...
            |                                           v
            |     +-------------------------------------+----------------+
            |     |             Flow Recording Process(*)                |
            |     | +----------------------+     +------------------+    |
            |     | | Flow data base       |<----|Provide non-flow  |    |
            |     | | (includes flows      |     | information (Eg. |    |
            |     | | from all obs.        |     | router state)    |    |
            |     | | points in an obs.    |     +------------------+
|.....
            |     | | domain)              |                             |
            |     | |                      |     +------------------+    |
            |     | |                      |<----|Maintain aggregate|    |
            |     | |                      |     | statistics       |    |
            |     | +----------------------+     +------------------+    |
            |     +-------------------------------+----------------------+
            |                                     |
            |        Flow Database (identified by observation domain)
            |
+------------------------....
            v                                     v
+-----------+-------------------------------------+--------------------------+

|           |            Export Process           |                          |

|           |                                     +----------------------... |

| +---------+------------------------------------------------------------+   |

| |         v                  IPFIX Protocol                            |   |

| |+---------------------------------+  +-------------------------------+|   |

| || Rules for                       |  |Functions                      ||   |

| || - Picking & sending templates   |  |- Packetize selected control   ||   |

| || - Picking & sending data records|->|  & data information into      ||   |

| || - Timing out flows              |  |  IPFIX export packet.         ||...|

| || - Encoding template & data      |  |- Handle export errors         ||   |

| || - Selecting flows for export(*) |  |- Handle timeouts & overloads  ||   |

| |+---------------------------------+  +-------------------------------+|   |

| |                                                                      |   |

| +-----------------------------+----------------------------------------+   |

|                               |                                            |

|                               +-----------------------------------------...|

|                     IPFIX exported packet                                  |

|                               |                                            |

| +-----------------------------+----------------------------------------+   |

| |                        Transport  Protocol                           |   |

| +-----------------------------+----------------------------------------+   |

|                               |                                            |

+-------------------------------+--------------------------------------------+

                                |
                                v
                        IPFIX export packet to collector.

(*) indicates that the block is optional.

Thanks
Ganesh



--------------5334ED95245CEA69A6807872
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>Hi,</tt>
<br><tt>&nbsp;&nbsp; I want to add this figure into the architecture spec.
Please go through this send</tt>
<br><tt>&nbsp;&nbsp; send any comments/corrections.</tt>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<tt></tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Packet(s) coming into Observation Point(s)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>&nbsp; +-----------------+-------------------------+&nbsp;&nbsp;
+-----+------+</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Metering Process on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Observation Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; packet header capturing&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Metering&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp; timestamping&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Process&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Observation|</tt>
<br><tt>&nbsp; |&nbsp; +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp; sampling Si (1:1 in case of no&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sampling)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; | classifying Fi (NULL when No criteria) |&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; +---------+---------------------------------+&nbsp;&nbsp;
+-----+------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flows (identified
by observation domain)&nbsp;&nbsp;&nbsp; Flows</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+--------+...</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; +-------------------------------------+----------------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Flow Recording Process(*)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | +----------------------+&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | Flow data base&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;----|Provide non-flow&nbsp; |&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | (includes flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | information (Eg. |&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | from all obs.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | router state)&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | points in an obs.&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp;&nbsp;&nbsp; |.....</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | domain)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; +------------------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;----|Maintain aggregate|&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | statistics&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | +----------------------+&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; +-------------------------------+----------------------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flow Database (identified by
observation domain)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+------------------------....</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>+-----------+-------------------------------------+--------------------------+</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Export Process&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----------------------... |</tt>
<br><tt>| +---------+------------------------------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IPFIX Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |</tt>
<br><tt>| |+---------------------------------+&nbsp; +-------------------------------+|&nbsp;&nbsp;
|</tt>
<br><tt>| || Rules for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |Functions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp; |</tt>
<br><tt>| || - Picking &amp; sending templates&nbsp;&nbsp; |&nbsp; |- Packetize
selected control&nbsp;&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| || - Picking &amp; sending data records|->|&nbsp; &amp; data
information into&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| || - Timing out flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |&nbsp; IPFIX export packet.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||...|</tt>
<br><tt>| || - Encoding template &amp; data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |- Handle export errors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp; |</tt>
<br><tt>| || - Selecting flows for export(*) |&nbsp; |- Handle timeouts
&amp; overloads&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| |+---------------------------------+&nbsp; +-------------------------------+|&nbsp;&nbsp;
|</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |</tt>
<br><tt>| +-----------------------------+----------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----------------------------------------...|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IPFIX exported packet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>| +-----------------------------+----------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Transport&nbsp; Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |</tt>
<br><tt>| +-----------------------------+----------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>+-------------------------------+--------------------------------------------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IPFIX export packet to collector.</tt><tt></tt>
<p><tt>(*) indicates that the block is optional.</tt><tt></tt>
<p><tt>Thanks</tt>
<br><tt>Ganesh</tt>
<br><tt></tt>&nbsp;
<br><tt></tt>&nbsp;</html>

--------------5334ED95245CEA69A6807872--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 11 15:41:07 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27964
	for <ipfix-archive@lists.ietf.org>; Wed, 11 Jun 2003 15:41:07 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QBAg-0006gX-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 14:22:10 -0500
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19QBAf-0006gQ-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 14:22:09 -0500
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5BJLje02934;
	Wed, 11 Jun 2003 14:21:46 -0500 (CDT)
Received: from zsc3c026.us.nortel.com ([47.81.138.26]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id LGTFNCQT; Wed, 11 Jun 2003 12:21:45 -0700
Received: from private2xsth6c (artpt5mz.us.nortel.com [47.140.52.51]) by zsc3c026.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id J4HAL6CL; Wed, 11 Jun 2003 12:21:45 -0700
Message-ID: <006201c3304e$bbda8af0$33348c2f@private2xsth6c>
X-Sybari-Space: 00000000 00000000 00000000
From: "Reinaldo Penno" <rpenno@nortelnetworks.com>
To: "Ganesh Sadasivan" <gsadasiv@cisco.com>, "Tal Givoly" <givoly@xacct.com>
Cc: <ipfix@net.doit.wisc.edu>
References: <DLEIIIOHMNPJPNMKGEFDIEFGDKAA.givoly@xacct.com> <3EE6719D.CE5ED0FA@cisco.com>
Subject: Re: [ipfix] Middle box functions
Date: Wed, 11 Jun 2003 15:22:00 -0400
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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

I guess the text is a little bit misleading...

The discussion at the time was that *if* the exporter is *also* performing
middlebox functions such as NAT, firewall, etc, it should let the collector
know that it is modifying the flows and what modifications it is doing
(dropping, translating addresses, etc).

reghards,

Reinaldo
----- Original Message -----
From: "Ganesh Sadasivan" <gsadasiv@cisco.com>
To: "Tal Givoly" <givoly@xacct.com>
Cc: <ipfix@net.doit.wisc.edu>
Sent: Tuesday, June 10, 2003 8:02 PM
Subject: Re: [ipfix] Middle box functions


> Sorry for the brevity.
> There is a line in the architecture spec. on the function of Observation
Domain.
>
> "Perform appropriate middle-box functions to translate the
> flow information."
>
> 1. This is not a function of the Observation Domain as it is a logical
block
> rather
> than a functional block.
> 2.It would be moslty a IPFIX protocol function in which case I would like
to put
>
> in some more words. So if someone can provide a few sentences stating what
is
> intended by "Middle box functions" I can put it into the arch. spec.
>
> Thanks
> Ganesh
>
> Tal Givoly wrote:
>
> > Ganesh,
> >
> > I personally didn't quite understand the question, perhaps you would
like to
> > elaborate or provide some more context for us to clarify/respond.
> >
> > Thanks,
> >
> > Tal
> >
> > -----Original Message-----
> > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> > Of Ganesh Sadasivan
> > Sent: Tuesday, June 10, 2003 1:49 PM
> > To: ipfix@net.doit.wisc.edu
> > Subject: [ipfix] Middle box functions
> >
> > Can someone restate what  "middle-box functions" need to be done
> > by an IPFIX device?
> >
> > 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/
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" 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 Jun 11 16:05:21 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20902
	for <ipfix-archive@lists.ietf.org>; Wed, 11 Jun 2003 16:05:21 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QBUw-0007UT-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 14:43:06 -0500
Received: from palrel13.hp.com ([156.153.255.238])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19QBUu-0007UJ-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 14:43:04 -0500
Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65])
	by palrel13.hp.com (Postfix) with ESMTP
	id 362C51C006BF; Wed, 11 Jun 2003 12:43:04 -0700 (PDT)
Received: from xpabh1.ptp.hp.com (xpabh1.ptp.hp.com [15.1.28.60])
	by xparelay2.ptp.hp.com (Postfix) with ESMTP
	id 1DC601C000B2; Wed, 11 Jun 2003 12:42:55 -0700 (PDT)
Received: by xpabh1.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <MPH3JC8X>; Wed, 11 Jun 2003 12:42:54 -0700
Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960071@xsun01.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ganesh Sadasivan'" <gsadasiv@cisco.com>, ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] IPFIX-ARCH : Functional flow diagram.
Date: Wed, 11 Jun 2003 12:42:51 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C33051.A4E12A90"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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_01C33051.A4E12A90
Content-Type: text/plain;
	charset="iso-8859-1"

Ganesh,
 
   Nice diagram.  Maybe someday IETF will move beyond ASCII art...  But this
is a fine example.
 
   In the exporter block I would make a few modifications:
 
| || Rules for                       |  |Functions                      ||
| 
| ||                                 |  |- Packetize selected control   ||
| 
| || - Picking & sending data records|->|  & data information into      ||
| 
| ||    and corresponding templates  |  |  IPFIX export packet.
||...| 
| || - Timing out flows              |  |- Handle export errors         ||
| 
| || - Selecting flows for export(*) |  |- Handle timeouts & overloads  ||
| 
 
 Specifically the data record and template selections are not independent.
You cannot send out a data record w/o sending a template.  There is no
reason to send a template if you will never send a data record of that form.
So, I'd merge these into one bullet point.
 
  I removed the "rules for encoding" since the function already states
"packetize control and data into export packets".  The rules seem to imply a
level of configurability of encoding which I don't think exists.
 
Regards,
 
  Jeff Meyer


-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Wednesday, June 11, 2003 11:58 AM
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] IPFIX-ARCH : Functional flow diagram.


Hi, 
   I want to add this figure into the architecture spec. Please go through
this send 
   send any comments/corrections. 
        
                    Packet(s) coming into Observation Point(s) 
                    |                                   | 
                    |                                   | 
                    v                                   v 
  +-----------------+-------------------------+   +-----+------+ 
  |           Metering Process on an          |   |            | 
  |              Observation Point            |   |            | 
  |  packet header capturing                  |   |            | 
  |         |                                 |   | Metering   | 
  |    timestamping                           |   | Process    | 
  |         |                                 |   | on an      | 
  |         v                                 |   | Observation| 
  |  +------+                                 |   | Point      | 
  |  |      |                                 |   |            | 
  |  |   sampling Si (1:1 in case of no       |   |            | 
  |  |      |          sampling)              |   |            | 
  |  | classifying Fi (NULL when No criteria) |   |            | 
  |  |      |                                 |   |            | 
  |  +------+                                 |   |            | 
  |         |                                 |   |            | 
  +---------+---------------------------------+   +-----+------+ 
            |                                           | 
          Flows (identified by observation domain)    Flows 
            +----...                                    +--------+... 
            |                                           v 
            |     +-------------------------------------+----------------+ 
            |     |             Flow Recording Process(*)                | 
            |     | +----------------------+     +------------------+    | 
            |     | | Flow data base       |<----|Provide non-flow  |    | 
            |     | | (includes flows      |     | information (Eg. |    | 
            |     | | from all obs.        |     | router state)    |    | 
            |     | | points in an obs.    |     +------------------+
|..... 
            |     | | domain)              |                             | 
            |     | |                      |     +------------------+    | 
            |     | |                      |<----|Maintain aggregate|    | 
            |     | |                      |     | statistics       |    | 
            |     | +----------------------+     +------------------+    | 
            |     +-------------------------------+----------------------+ 
            |                                     | 
            |        Flow Database (identified by observation domain) 
            |
+------------------------.... 
            v                                     v 
+-----------+-------------------------------------+-------------------------
-+ 
|           |            Export Process           |
| 
|           |                                     +----------------------...
| 
| +---------+------------------------------------------------------------+
| 
| |         v                  IPFIX Protocol                            |
| 
| |+---------------------------------+  +-------------------------------+|
| 
| || Rules for                       |  |Functions                      ||
| 
| || - Picking & sending templates   |  |- Packetize selected control   ||
| 
| || - Picking & sending data records|->|  & data information into      ||
| 
| || - Timing out flows              |  |  IPFIX export packet.
||...| 
| || - Encoding template & data      |  |- Handle export errors         ||
| 
| || - Selecting flows for export(*) |  |- Handle timeouts & overloads  ||
| 
| |+---------------------------------+  +-------------------------------+|
| 
| |                                                                      |
| 
| +-----------------------------+----------------------------------------+
| 
|                               |
| 
|
+-----------------------------------------...| 
|                     IPFIX exported packet
| 
|                               |
| 
| +-----------------------------+----------------------------------------+
| 
| |                        Transport  Protocol                           |
| 
| +-----------------------------+----------------------------------------+
| 
|                               |
| 
+-------------------------------+-------------------------------------------
-+ 
                                | 
                                v 
                        IPFIX export packet to collector. 

(*) indicates that the block is optional. 


Thanks 
Ganesh 
  
  


------_=_NextPart_001_01C33051.A4E12A90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.50.4915.500" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D046484219-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Ganesh,</FONT></SPAN></DIV>
<DIV><SPAN class=3D046484219-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D046484219-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp; Nice diagram.&nbsp; Maybe someday IETF will move =
beyond=20
ASCII art...&nbsp; But this is a fine example.</FONT></SPAN></DIV>
<DIV><SPAN class=3D046484219-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D046484219-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp; In the exporter block I would make a few=20
modifications:</FONT></SPAN></DIV>
<DIV><SPAN class=3D046484219-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D046484219-11062003><FONT face=3D"Courier New">| || =
Rules=20
for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;=20
|Functions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
||&nbsp;&nbsp; |</FONT> <BR><TT>|=20
||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp; |- Packetize selected control&nbsp;&nbsp; ||&nbsp;&nbsp; |</TT> =

<BR><TT>| || - Picking &amp; sending </TT></SPAN><SPAN=20
class=3D046484219-11062003><TT>data records|-&gt;|&nbsp; &amp; data =
information=20
into&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp; |</TT> <BR><TT>|=20
||&nbsp;&nbsp;&nbsp; and corresponding templates&nbsp; |&nbsp; |&nbsp; =
IPFIX=20
export packet.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
||...|</TT>=20
<BR><TT>| ||&nbsp;- Timing out=20
flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
|&nbsp; |- Handle export =
errors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
||&nbsp;&nbsp; |</TT> <BR><TT>| || - Selecting flows for export(*) =
|&nbsp; |-=20
Handle timeouts &amp; overloads&nbsp; ||&nbsp;&nbsp; |</TT> =
</SPAN></DIV>
<DIV><SPAN class=3D046484219-11062003><FONT=20
face=3D"Courier New"></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D046484219-11062003><FONT face=3D"Courier =
New">&nbsp;</FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2>Specifically the data record and =
template=20
selections are not independent.&nbsp; You cannot send out a data record =
w/o=20
sending a template.&nbsp; There is no reason to send a template if you =
will=20
never send a data record of that form.&nbsp; So, I'd merge these into =
one bullet=20
point.</FONT></SPAN></DIV>
<DIV><SPAN class=3D046484219-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D046484219-11062003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
I removed the "rules for encoding" since the function already states =
"packetize=20
control and data into export packets".&nbsp; The rules seem to imply a =
level of=20
configurability of encoding which I don't think =
exists.</FONT></SPAN></DIV>
<DIV><SPAN class=3D046484219-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D046484219-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D046484219-11062003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D046484219-11062003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
Jeff Meyer</FONT></DIV>
<DIV><BR></DIV></SPAN>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Ganesh Sadasivan=20
  [mailto:gsadasiv@cisco.com]<BR><B>Sent:</B> Wednesday, June 11, 2003 =
11:58=20
  AM<BR><B>To:</B> ipfix@net.doit.wisc.edu<BR><B>Subject:</B> [ipfix] =
IPFIX-ARCH=20
  : Functional flow diagram.<BR><BR></FONT></DIV><TT>Hi,</TT>=20
  <BR><TT>&nbsp;&nbsp; I want to add this figure into the architecture =
spec.=20
  Please go through this send</TT> <BR><TT>&nbsp;&nbsp; send any=20
  comments/corrections.</TT>=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<TT></TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Packet(s) coming into Observation Point(s)</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  v</TT> <BR><TT>&nbsp;=20
  +-----------------+-------------------------+&nbsp;&nbsp; =
+-----+------+</TT>=20
  <BR><TT>&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Metering Process on =
an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
  Observation=20
  =
Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; |&nbsp; packet header=20
  =
capturing&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; | Metering&nbsp;&nbsp; |</TT> <BR><TT>&nbsp; =
|&nbsp;&nbsp;&nbsp;=20
  =
timestamping&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; | Process&nbsp;&nbsp;&nbsp; |</TT> <BR><TT>&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; | on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> =
<BR><TT>&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; | Observation|</TT> <BR><TT>&nbsp; |&nbsp;=20
  =
+------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; | Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> =
<BR><TT>&nbsp;=20
  |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; |&nbsp; |&nbsp;&nbsp; sampling Si (1:1 in case of=20
  no&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
sampling)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; |&nbsp; | classifying Fi (NULL when No criteria) =
|&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; |&nbsp;=20
  =
+------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; =
+---------+---------------------------------+&nbsp;&nbsp;=20
  +-----+------+</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Flows=20
  (identified by observation domain)&nbsp;&nbsp;&nbsp; Flows</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  =
+----...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  +--------+...</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  v</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------------------------------------+----------------+</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Flow=20
  Recording=20
  =
Process(*)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | =
+----------------------+&nbsp;&nbsp;&nbsp;&nbsp;=20
  +------------------+&nbsp;&nbsp;&nbsp; |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | | Flow data=20
  base&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&lt;----|Provide =
non-flow&nbsp;=20
  |&nbsp;&nbsp;&nbsp; |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | | (includes =
flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | information (Eg. |&nbsp;&nbsp;&nbsp; =
|</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | | from all=20
  obs.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp; |=20
  router state)&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | | points in an obs.&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; +------------------+&nbsp;&nbsp;&nbsp; =
|.....</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | |=20
  =
domain)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; |=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; +------------------+&nbsp;&nbsp;&nbsp; =
|</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; |=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&lt;----|Maintain aggregate|&nbsp;&nbsp;&nbsp; |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; |=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | =
statistics&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp; |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | =
+----------------------+&nbsp;&nbsp;&nbsp;&nbsp;=20
  +------------------+&nbsp;&nbsp;&nbsp; |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------------------------------+----------------------+</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flow Database (identified =
by=20
  observation domain)</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  +------------------------....</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  =
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  v</TT>=20
  <BR><TT>+-----------+-------------------------------------+-----------=
---------------+</TT>=20
  <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Export=20
  Process&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
  |</TT> =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  +----------------------... |</TT> <BR><TT>|=20
  =
+---------+------------------------------------------------------------+=
&nbsp;&nbsp;=20
  |</TT> <BR><TT>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  IPFIX=20
  =
Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; |</TT> <BR><TT>| =
|+---------------------------------+&nbsp;=20
  +-------------------------------+|&nbsp;&nbsp; |</TT> <BR><TT>| || =
Rules=20
  =
for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;=20
  =
|Functions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  ||&nbsp;&nbsp; |</TT> <BR><TT>| || - Picking &amp; sending=20
  templates&nbsp;&nbsp; |&nbsp; |- Packetize selected =
control&nbsp;&nbsp;=20
  ||&nbsp;&nbsp; |</TT> <BR><TT>| || - Picking &amp; sending data=20
  records|-&gt;|&nbsp; &amp; data information =
into&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  ||&nbsp;&nbsp; |</TT> <BR><TT>| || - Timing out=20
  =
flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
  |&nbsp; |&nbsp; IPFIX export=20
  packet.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||...|</TT> =
<BR><TT>|=20
  || - Encoding template &amp; data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp; |-=20
  Handle export errors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  ||&nbsp;&nbsp; |</TT> <BR><TT>| || - Selecting flows for export(*) =
|&nbsp; |-=20
  Handle timeouts &amp; overloads&nbsp; ||&nbsp;&nbsp; |</TT> <BR><TT>| =

  |+---------------------------------+&nbsp;=20
  +-------------------------------+|&nbsp;&nbsp; |</TT> <BR><TT>|=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; |</TT> <BR><TT>|=20
  =
+-----------------------------+----------------------------------------+=
&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-----------------------------------------...|</TT>=20
  =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  IPFIX exported=20
  =
packet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT> <BR><TT>|=20
  =
+-----------------------------+----------------------------------------+=
&nbsp;&nbsp;=20
  |</TT> <BR><TT>|=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Transport&nbsp;=20
  =
Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; |</TT> <BR><TT>|=20
  =
+-----------------------------+----------------------------------------+=
&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>+-------------------------------+-------------------------------=
-------------+</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  v</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
  IPFIX export packet to collector.</TT><TT></TT>=20
  <P><TT>(*) indicates that the block is optional.</TT><TT></TT>=20
  <P><TT>Thanks</TT> <BR><TT>Ganesh</TT> <BR><TT></TT>&nbsp; =
<BR><TT></TT>&nbsp;=20
  </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C33051.A4E12A90--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 11 17:52:25 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04807
	for <ipfix-archive@lists.ietf.org>; Wed, 11 Jun 2003 17:52:25 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QDCM-0002cA-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 16:32:02 -0500
Received: from halt-in.cisco.com ([171.70.144.185])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19QDCL-0002bq-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 16:32:01 -0500
Received: from cisco.com (171.71.163.13)
  by halt-in.cisco.com with ESMTP; 11 Jun 2003 14:31:53 -0800
Received: from cisco.com (dhcp-171-71-204-251.cisco.com [171.71.204.251])
	by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AHE25380;
	Wed, 11 Jun 2003 14:38:36 -0700 (PDT)
Message-ID: <3EE79FCF.6E8859F5@cisco.com>
Date: Wed, 11 Jun 2003 14:31:59 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Reinaldo Penno <rpenno@nortelnetworks.com>
CC: Tal Givoly <givoly@xacct.com>, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Middle box functions
References: <DLEIIIOHMNPJPNMKGEFDIEFGDKAA.givoly@xacct.com> <3EE6719D.CE5ED0FA@cisco.com> <006201c3304e$bbda8af0$33348c2f@private2xsth6c>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



Reinaldo Penno wrote:

> I guess the text is a little bit misleading...
>
> The discussion at the time was that *if* the exporter is *also* performing
> middlebox functions such as NAT, firewall, etc, it should let the collector
> know that it is modifying the flows and what modifications it is doing
> (dropping, translating addresses, etc).

So what was the decision on this topic?

Thanks
Ganesh

>
>
> reghards,
>
> Reinaldo
> ----- Original Message -----
> From: "Ganesh Sadasivan" <gsadasiv@cisco.com>
> To: "Tal Givoly" <givoly@xacct.com>
> Cc: <ipfix@net.doit.wisc.edu>
> Sent: Tuesday, June 10, 2003 8:02 PM
> Subject: Re: [ipfix] Middle box functions
>
> > Sorry for the brevity.
> > There is a line in the architecture spec. on the function of Observation
> Domain.
> >
> > "Perform appropriate middle-box functions to translate the
> > flow information."
> >
> > 1. This is not a function of the Observation Domain as it is a logical
> block
> > rather
> > than a functional block.
> > 2.It would be moslty a IPFIX protocol function in which case I would like
> to put
> >
> > in some more words. So if someone can provide a few sentences stating what
> is
> > intended by "Middle box functions" I can put it into the arch. spec.
> >
> > Thanks
> > Ganesh
> >
> > Tal Givoly wrote:
> >
> > > Ganesh,
> > >
> > > I personally didn't quite understand the question, perhaps you would
> like to
> > > elaborate or provide some more context for us to clarify/respond.
> > >
> > > Thanks,
> > >
> > > Tal
> > >
> > > -----Original Message-----
> > > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> > > Of Ganesh Sadasivan
> > > Sent: Tuesday, June 10, 2003 1:49 PM
> > > To: ipfix@net.doit.wisc.edu
> > > Subject: [ipfix] Middle box functions
> > >
> > > Can someone restate what  "middle-box functions" need to be done
> > > by an IPFIX device?
> > >
> > > 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/
> >
> > --
> > Help        mailto:majordomo@net.doit.wisc.edu and say "help" 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 Jun 11 18:04:41 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05356
	for <ipfix-archive@lists.ietf.org>; Wed, 11 Jun 2003 18:04:40 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QDIe-0002jw-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 16:38:32 -0500
Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19QDId-0002jq-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 16:38:31 -0500
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28])
	by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5BLbtf25404;
	Wed, 11 Jun 2003 14:37:56 -0700 (PDT)
Received: from zsc3c026.us.nortel.com ([47.81.138.26]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id LGTFNNB9; Wed, 11 Jun 2003 14:37:56 -0700
Received: from private2xsth6c (artpt5mz.us.nortel.com [47.140.52.51]) by zsc3c026.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id J4HAL6FG; Wed, 11 Jun 2003 14:37:56 -0700
Message-ID: <00ae01c33061$c1d04a40$33348c2f@private2xsth6c>
X-Sybari-Space: 00000000 00000000 00000000
From: "Reinaldo Penno" <rpenno@nortelnetworks.com>
To: "Ganesh Sadasivan" <gsadasiv@cisco.com>,
        "Reinaldo Penno" <rpenno@nortelnetworks.com>
Cc: "Tal Givoly" <givoly@xacct.com>, <ipfix@net.doit.wisc.edu>
References: <DLEIIIOHMNPJPNMKGEFDIEFGDKAA.givoly@xacct.com> <3EE6719D.CE5ED0FA@cisco.com> <006201c3304e$bbda8af0$33348c2f@private2xsth6c> <3EE79FCF.6E8859F5@cisco.com>
Subject: Re: [ipfix] Middle box functions
Date: Wed, 11 Jun 2003 17:38:10 -0400
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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

In the "original" data model there were fields to represent translated
addresses, ports, etc, etc

Not sure how it is today. Maybe we should ask the list and see if people
think sending modified flow information (dropped, translated, shaped, etc)
is useful and what degree of compliance is needed (MUST, SHOULD or MAY).

IMO I would like to know such information.

regards,

Reinaldo

----- Original Message -----
From: "Ganesh Sadasivan" <gsadasiv@cisco.com>
To: "Penno, Reinaldo [BL60:SB20:EXCH]" <rpenno@americasm06.nt.com>
Cc: "Tal Givoly" <givoly@xacct.com>; <ipfix@net.doit.wisc.edu>
Sent: Wednesday, June 11, 2003 5:31 PM
Subject: Re: [ipfix] Middle box functions


>
>
> Reinaldo Penno wrote:
>
> > I guess the text is a little bit misleading...
> >
> > The discussion at the time was that *if* the exporter is *also*
performing
> > middlebox functions such as NAT, firewall, etc, it should let the
collector
> > know that it is modifying the flows and what modifications it is doing
> > (dropping, translating addresses, etc).
>
> So what was the decision on this topic?
>
> Thanks
> Ganesh
>
> >
> >
> > reghards,
> >
> > Reinaldo
> > ----- Original Message -----
> > From: "Ganesh Sadasivan" <gsadasiv@cisco.com>
> > To: "Tal Givoly" <givoly@xacct.com>
> > Cc: <ipfix@net.doit.wisc.edu>
> > Sent: Tuesday, June 10, 2003 8:02 PM
> > Subject: Re: [ipfix] Middle box functions
> >
> > > Sorry for the brevity.
> > > There is a line in the architecture spec. on the function of
Observation
> > Domain.
> > >
> > > "Perform appropriate middle-box functions to translate the
> > > flow information."
> > >
> > > 1. This is not a function of the Observation Domain as it is a logical
> > block
> > > rather
> > > than a functional block.
> > > 2.It would be moslty a IPFIX protocol function in which case I would
like
> > to put
> > >
> > > in some more words. So if someone can provide a few sentences stating
what
> > is
> > > intended by "Middle box functions" I can put it into the arch. spec.
> > >
> > > Thanks
> > > Ganesh
> > >
> > > Tal Givoly wrote:
> > >
> > > > Ganesh,
> > > >
> > > > I personally didn't quite understand the question, perhaps you would
> > like to
> > > > elaborate or provide some more context for us to clarify/respond.
> > > >
> > > > Thanks,
> > > >
> > > > Tal
> > > >
> > > > -----Original Message-----
> > > > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On
Behalf
> > > > Of Ganesh Sadasivan
> > > > Sent: Tuesday, June 10, 2003 1:49 PM
> > > > To: ipfix@net.doit.wisc.edu
> > > > Subject: [ipfix] Middle box functions
> > > >
> > > > Can someone restate what  "middle-box functions" need to be done
> > > > by an IPFIX device?
> > > >
> > > > 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/
> > >
> > > --
> > > Help        mailto:majordomo@net.doit.wisc.edu and say "help" 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 Jun 11 19:27:11 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09260
	for <ipfix-archive@lists.ietf.org>; Wed, 11 Jun 2003 19:27:11 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QEqc-0005Lt-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 18:17:42 -0500
Received: from halt-in.cisco.com ([171.70.144.185])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19QEqb-0005Lo-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 18:17:41 -0500
Received: from cisco.com (171.71.163.13)
  by halt-in.cisco.com with ESMTP; 11 Jun 2003 16:17:29 -0800
Received: from cisco.com (dhcp-171-71-204-251.cisco.com [171.71.204.251])
	by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AHE26297;
	Wed, 11 Jun 2003 14:47:28 -0700 (PDT)
Message-ID: <3EE7A1E3.8B81A635@cisco.com>
Date: Wed, 11 Jun 2003 14:40:52 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] IPFIX-ARCH : Functional flow diagram.
References: <1D3D2C371FCBD947A7897FABBD3533A502960071@xsun01.ptp.hp.com>
Content-Type: multipart/alternative;
 boundary="------------8B467228E422DB590691B21C"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


--------------8B467228E422DB590691B21C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jeff,

   - Regarding
   "Picking & sending data records and corresponding templates "
   I  separated this out because the arch. spec does not dictate the
rules for sending
   templates & corresponding data. That is more of a protocol decision.

   -Regarding "rules for encoding"
   The kind of information I was thinking is if some one want to use
more refined encoding
   Eg. If the flow collection is done on IP address, but the address
itself is encoded as
   a "aa.bb.cc.dd" string.
   Is this something we should be allowing to be supported (as a MAY) ?

Thanks
Ganesh




"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:

>  Ganesh,   Nice diagram.  Maybe someday IETF will move beyond ASCII
> art...  But this is a fine example.   In the exporter block I would
> make a few modifications:| || Rules for                       |
> |Functions                      ||   |
> | ||                                 |  |- Packetize selected
> control   ||   |
> | || - Picking & sending data records|->|  & data information
> into      ||   |
> | ||    and corresponding templates  |  |  IPFIX export
> packet.         ||...|
> | || - Timing out flows              |  |- Handle export
> errors         ||   |
> | || - Selecting flows for export(*) |  |- Handle timeouts &
> overloads  ||   | Specifically the data record and template selections
> are not independent.  You cannot send out a data record w/o sending a
> template.  There is no reason to send a template if you will never
> send a data record of that form.  So, I'd merge these into one bullet
> point.
>
>        I removed the " " since the function already states
>      "packetize control and data into export packets".  The rules
>      seem to imply a level of configurability of encoding which I
>      don't think exists.Regards,  Jeff Meyer
>
>      -----Original Message-----
>      From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
>      Sent: Wednesday, June 11, 2003 11:58 AM
>      To: ipfix@net.doit.wisc.edu
>      Subject: [ipfix] IPFIX-ARCH : Functional flow diagram.
>
>      Hi,
>         I want to add this figure into the architecture spec.
>      Please go through this send
>         send any comments/corrections.
>
>                          Packet(s) coming into Observation
>      Point(s)
>                          |                                   |
>                          |                                   |
>                          v                                   v
>        +-----------------+-------------------------+
>      +-----+------+
>        |           Metering Process on an          |
>      |            |
>        |              Observation Point            |
>      |            |
>        |  packet header capturing                  |
>      |            |
>        |         |                                 |   |
>      Metering   |
>        |    timestamping                           |   |
>      Process    |
>        |         |                                 |   | on
>      an      |
>        |         v                                 |   |
>      Observation|
>        |  +------+                                 |   |
>      Point      |
>        |  |      |                                 |
>      |            |
>        |  |   sampling Si (1:1 in case of no       |
>      |            |
>        |  |      |          sampling)              |
>      |            |
>        |  | classifying Fi (NULL when No criteria) |
>      |            |
>        |  |      |                                 |
>      |            |
>        |  +------+                                 |
>      |            |
>        |         |                                 |
>      |            |
>        +---------+---------------------------------+
>      +-----+------+
>                  |                                           |
>                Flows (identified by observation domain)    Flows
>                  +----...
>      +--------+...
>                  |                                           v
>                  |
>      +-------------------------------------+----------------+
>                  |     |             Flow Recording
>      Process(*)                |
>                  |     | +----------------------+
>      +------------------+    |
>                  |     | | Flow data base       |<----|Provide
>      non-flow  |    |
>                  |     | | (includes flows      |     |
>      information (Eg. |    |
>                  |     | | from all obs.        |     | router
>      state)    |    |
>                  |     | | points in an obs.    |
>      +------------------+    |.....
>                  |     | | domain)
>      |                             |
>                  |     | |                      |
>      +------------------+    |
>                  |     | |                      |<----|Maintain
>      aggregate|    |
>                  |     | |                      |     |
>      statistics       |    |
>                  |     | +----------------------+
>      +------------------+    |
>                  |
>      +-------------------------------+----------------------+
>                  |                                     |
>                  |        Flow Database (identified by
>      observation domain)
>                  |
>      +------------------------....
>                  v                                     v
>
>      -----------+-------------------------------------+--------------------------+
>
>      |           |            Export Process
>      |                          |
>      |           |
>      +----------------------... |
>      |
>      +---------+------------------------------------------------------------+
>      |
>      | |         v                  IPFIX
>      Protocol                            |   |
>      | |+---------------------------------+
>      +-------------------------------+|   |
>      | || Rules for                       |
>      |Functions                      ||   |
>      | || - Picking & sending templates   |  |- Packetize
>      selected control   ||   |
>      | || - Picking & sending data records|->|  & data
>      information into      ||   |
>      | || - Timing out flows              |  |  IPFIX export
>      packet.         ||...|
>      | || - Encoding template & data      |  |- Handle export
>      errors         ||   |
>      | || - Selecting flows for export(*) |  |- Handle timeouts &
>      overloads  ||   |
>      | |+---------------------------------+
>      +-------------------------------+|   |
>      |
>      |
>      |   |
>      |
>      +-----------------------------+----------------------------------------+
>      |
>      |
>      |                                            |
>      |
>      +-----------------------------------------...|
>      |                     IPFIX exported
>      packet                                  |
>      |
>      |                                            |
>      |
>      +-----------------------------+----------------------------------------+
>      |
>      | |                        Transport
>      Protocol                           |   |
>      |
>      +-----------------------------+----------------------------------------+
>      |
>      |
>      |                                            |
>
>      -------------------------------+--------------------------------------------+
>
>                                      |
>                                      v
>                              IPFIX export packet to collector.
>
>      (*) indicates that the block is optional.
>
>      Thanks
>      Ganesh
>
>
>

--------------8B467228E422DB590691B21C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Jeff,
<p>&nbsp;&nbsp; - Regarding
<br>&nbsp;&nbsp; "P<tt>icking &amp; sending data records and corresponding
templates "</tt>
<br>&nbsp;&nbsp; I&nbsp; separated this out because the arch. spec does
not dictate the rules for sending
<br>&nbsp;&nbsp; templates &amp; corresponding data. That is more of a
protocol decision.
<p>&nbsp;&nbsp; -Regarding "<font face="Arial"><font color="#000000"><font size=-1>rules
for encoding"</font></font></font>
<br><font color="#000000"><font face="Arial"><font size=-1>&nbsp;&nbsp;
</font></font>The kind of information I was thinking is if some one want
to use more refined encoding</font>
<br><font color="#000000">&nbsp;&nbsp; Eg. If the flow collection is done
on IP address, but the address itself is encoded as</font>
<br><font color="#000000">&nbsp;&nbsp; a "aa.bb.cc.dd" string.</font>
<br><font color="#000000">&nbsp;&nbsp; Is this something we should be allowing
to be supported (as a MAY) ?</font><font face="Arial"><font color="#000000"><font size=-1></font></font></font>
<p><font face="Arial"><font color="#000000"><font size=-1>Thanks</font></font></font>
<br><font face="Arial"><font color="#000000"><font size=-1>Ganesh</font></font></font>
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p>"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
<blockquote TYPE=CITE>&nbsp;<span class=046484219-11062003><font face="Arial"><font color="#0000FF"><font size=-1>Ganesh,</font></font></font></span><span class=046484219-11062003></span><span class=046484219-11062003><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;
Nice diagram.&nbsp; Maybe someday IETF will move beyond ASCII art...&nbsp;
But this is a fine example.</font></font></font></span><span class=046484219-11062003></span><span class=046484219-11062003><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;
In the exporter block I would make a few modifications:</font></font></font></span><span class=046484219-11062003></span><span class=046484219-11062003><font face="Courier New">|
|| Rules for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |Functions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp; |</font>
<br><tt>| ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |- Packetize selected control&nbsp;&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| || - Picking &amp; sending&nbsp;</span><span 
class=046484219-11062003>data
records|->|&nbsp; &amp; data information into&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp; |</tt>
<br><tt>| ||&nbsp;&nbsp;&nbsp; and corresponding templates&nbsp; |&nbsp;
|&nbsp; IPFIX export packet.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||...|</tt>
<br><tt>| || - Timing out flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |- Handle export errors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp; |</tt>
<br><tt>| || - Selecting flows for export(*) |&nbsp; |- Handle timeouts
&amp; overloads&nbsp; ||&nbsp;&nbsp; |</tt></span><span class=046484219-11062003></span><span class=046484219-11062003><font face="Courier New">
</font><font face="Arial"><font color="#0000FF"><font size=-1>Specifically
the data record and template selections are not independent.&nbsp; You
cannot send out a data record w/o sending a template.&nbsp; There is no
reason to send a template if you will never send a data record of that
form.&nbsp; So, I'd merge these into one bullet point.</font></font></font>
<blockquote dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<div class="OutlookMessageHeader" dir="ltr"><span class=046484219-11062003><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;
I removed the " " since the function already states "packetize control
and data into export packets".&nbsp; The rules seem to imply a level of
configurability of encoding which I don't think exists.</font></font></font></span><span class=046484219-11062003></span><span class=046484219-11062003><font face="Arial"><font color="#0000FF"><font size=-1>Regards,</font></font></font></span><span class=046484219-11062003></span><span class=046484219-11062003><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;
Jeff Meyer</font></font></font>&nbsp;</span><font size=-1></font>
<p><font face="Tahoma"><font size=-1>-----Original Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Ganesh Sadasivan [<A HREF="mailto:gsadasiv@cisco.com">mailto:gsadasiv@cisco.com</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Wednesday, June 11,
2003 11:58 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> ipfix@net.doit.wisc.edu</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> [ipfix] IPFIX-ARCH
: Functional flow diagram.</font></font>
<br>&nbsp;</div>
<tt>Hi,</tt>
<br><tt>&nbsp;&nbsp; I want to add this figure into the architecture spec.
Please go through this send</tt>
<br><tt>&nbsp;&nbsp; send any comments/corrections.</tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Packet(s) coming into Observation Point(s)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>&nbsp; +-----------------+-------------------------+&nbsp;&nbsp;
+-----+------+</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Metering Process on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Observation Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; packet header capturing&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Metering&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp; timestamping&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Process&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Observation|</tt>
<br><tt>&nbsp; |&nbsp; +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp; sampling Si (1:1 in case of no&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sampling)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; | classifying Fi (NULL when No criteria) |&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; +---------+---------------------------------+&nbsp;&nbsp;
+-----+------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flows (identified
by observation domain)&nbsp;&nbsp;&nbsp; Flows</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+--------+...</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; +-------------------------------------+----------------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Flow Recording Process(*)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | +----------------------+&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | Flow data base&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;----|Provide non-flow&nbsp; |&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | (includes flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | information (Eg. |&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | from all obs.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | router state)&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | points in an obs.&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp;&nbsp;&nbsp; |.....</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | domain)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; +------------------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;----|Maintain aggregate|&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | statistics&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | +----------------------+&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; +-------------------------------+----------------------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flow Database (identified by
observation domain)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+------------------------....</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>+-----------+-------------------------------------+--------------------------+</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Export Process&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----------------------... |</tt>
<br><tt>| +---------+------------------------------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IPFIX Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |</tt>
<br><tt>| |+---------------------------------+&nbsp; +-------------------------------+|&nbsp;&nbsp;
|</tt>
<br><tt>| || Rules for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |Functions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp; |</tt>
<br><tt>| || - Picking &amp; sending templates&nbsp;&nbsp; |&nbsp; |- Packetize
selected control&nbsp;&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| || - Picking &amp; sending data records|->|&nbsp; &amp; data
information into&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| || - Timing out flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |&nbsp; IPFIX export packet.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||...|</tt>
<br><tt>| || - Encoding template &amp; data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |- Handle export errors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp; |</tt>
<br><tt>| || - Selecting flows for export(*) |&nbsp; |- Handle timeouts
&amp; overloads&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| |+---------------------------------+&nbsp; +-------------------------------+|&nbsp;&nbsp;
|</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |</tt>
<br><tt>| +-----------------------------+----------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----------------------------------------...|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IPFIX exported packet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>| +-----------------------------+----------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Transport&nbsp; Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |</tt>
<br><tt>| +-----------------------------+----------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>+-------------------------------+--------------------------------------------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IPFIX export packet to collector.</tt>
<p><tt>(*) indicates that the block is optional.</tt>
<p><tt>Thanks</tt>
<br><tt>Ganesh</tt>
<br>&nbsp;
<br>&nbsp;</blockquote>
</blockquote>
</html>

--------------8B467228E422DB590691B21C--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 11 20:08:15 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10057
	for <ipfix-archive@lists.ietf.org>; Wed, 11 Jun 2003 20:08:15 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QFKW-00066z-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 18:48:36 -0500
Received: from palrel12.hp.com ([156.153.255.237])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19QFKV-00066u-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 18:48:35 -0500
Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65])
	by palrel12.hp.com (Postfix) with ESMTP
	id 838451C013DE; Wed, 11 Jun 2003 16:48:34 -0700 (PDT)
Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63])
	by xparelay2.ptp.hp.com (Postfix) with ESMTP
	id 5FCE91C000A2; Wed, 11 Jun 2003 16:48:34 -0700 (PDT)
Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <M4FSVK0J>; Wed, 11 Jun 2003 16:48:33 -0700
Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960075@xsun01.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ganesh Sadasivan'" <gsadasiv@cisco.com>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
Cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] IPFIX-ARCH : Functional flow diagram.
Date: Wed, 11 Jun 2003 16:47:47 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C33073.DCC4E790"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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_01C33073.DCC4E790
Content-Type: text/plain;
	charset="iso-8859-1"

Ganesh,
 
  The use of templates overall is a protocol decision, keep in mind that
other candidates, such as Diameter are not template oriented.  So, from an
architecture perspective, I guess templates should not be mentioned at all,
they are strictly an artifact of the protocol.
 
  I don't think I follow your point regarding the second item, "rules for
encoding".  Is anonymization an example of encoding, or simple translation
of formats (e.g. ipaddr -> string)?  In either case, this sounds more
protocol'ish than architecture.
 
-- Jeff

-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Wednesday, June 11, 2003 2:41 PM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] IPFIX-ARCH : Functional flow diagram.


Jeff, 

   - Regarding 
   "Picking & sending data records and corresponding templates " 
   I  separated this out because the arch. spec does not dictate the rules
for sending 
   templates & corresponding data. That is more of a protocol decision. 


   -Regarding "rules for encoding" 
   The kind of information I was thinking is if some one want to use more
refined encoding 
   Eg. If the flow collection is done on IP address, but the address itself
is encoded as 
   a "aa.bb.cc.dd" string. 
   Is this something we should be allowing to be supported (as a MAY) ? 


Thanks 
Ganesh 
  
  
  


"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote: 


 Ganesh,   Nice diagram.  Maybe someday IETF will move beyond ASCII art...
But this is a fine example.   In the exporter block I would make a few
modifications:| || Rules for                       |  |Functions
||   | 
| ||                                 |  |- Packetize selected control   ||
| 
| || - Picking & sending data records|->|  & data information into      ||
| 
| ||    and corresponding templates  |  |  IPFIX export packet.
||...| 
| || - Timing out flows              |  |- Handle export errors         ||
| 
| || - Selecting flows for export(*) |  |- Handle timeouts & overloads  ||
| Specifically the data record and template selections are not independent.
You cannot send out a data record w/o sending a template.  There is no
reason to send a template if you will never send a data record of that form.
So, I'd merge these into one bullet point. 

  I removed the " " since the function already states "packetize control and
data into export packets".  The rules seem to imply a level of
configurability of encoding which I don't think exists.Regards,  Jeff Meyer


-----Original Message----- 
From: Ganesh Sadasivan [ mailto:gsadasiv@cisco.com
<mailto:gsadasiv@cisco.com> ] 
Sent: Wednesday, June 11, 2003 11:58 AM 
To: ipfix@net.doit.wisc.edu 
Subject: [ipfix] IPFIX-ARCH : Functional flow diagram. 
 

Hi, 
   I want to add this figure into the architecture spec. Please go through
this send 
   send any comments/corrections. 

                    Packet(s) coming into Observation Point(s) 
                    |                                   | 
                    |                                   | 
                    v                                   v 
  +-----------------+-------------------------+   +-----+------+ 
  |           Metering Process on an          |   |            | 
  |              Observation Point            |   |            | 
  |  packet header capturing                  |   |            | 
  |         |                                 |   | Metering   | 
  |    timestamping                           |   | Process    | 
  |         |                                 |   | on an      | 
  |         v                                 |   | Observation| 
  |  +------+                                 |   | Point      | 
  |  |      |                                 |   |            | 
  |  |   sampling Si (1:1 in case of no       |   |            | 
  |  |      |          sampling)              |   |            | 
  |  | classifying Fi (NULL when No criteria) |   |            | 
  |  |      |                                 |   |            | 
  |  +------+                                 |   |            | 
  |         |                                 |   |            | 
  +---------+---------------------------------+   +-----+------+ 
            |                                           | 
          Flows (identified by observation domain)    Flows 
            +----...                                    +--------+... 
            |                                           v 
            |     +-------------------------------------+----------------+ 
            |     |             Flow Recording Process(*)                | 
            |     | +----------------------+     +------------------+    | 
            |     | | Flow data base       |<----|Provide non-flow  |    | 
            |     | | (includes flows      |     | information (Eg. |    | 
            |     | | from all obs.        |     | router state)    |    | 
            |     | | points in an obs.    |     +------------------+
|..... 
            |     | | domain)              |                             | 
            |     | |                      |     +------------------+    | 
            |     | |                      |<----|Maintain aggregate|    | 
            |     | |                      |     | statistics       |    | 
            |     | +----------------------+     +------------------+    | 
            |     +-------------------------------+----------------------+ 
            |                                     | 
            |        Flow Database (identified by observation domain) 
            |
+------------------------.... 
            v                                     v 
+-----------+-------------------------------------+-------------------------
-+ 
|           |            Export Process           |
| 
|           |                                     +----------------------...
| 
| +---------+------------------------------------------------------------+
| 
| |         v                  IPFIX Protocol                            |
| 
| |+---------------------------------+  +-------------------------------+|
| 
| || Rules for                       |  |Functions                      ||
| 
| || - Picking & sending templates   |  |- Packetize selected control   ||
| 
| || - Picking & sending data records|->|  & data information into      ||
| 
| || - Timing out flows              |  |  IPFIX export packet.
||...| 
| || - Encoding template & data      |  |- Handle export errors         ||
| 
| || - Selecting flows for export(*) |  |- Handle timeouts & overloads  ||
| 
| |+---------------------------------+  +-------------------------------+|
| 
| |                                                                      |
| 
| +-----------------------------+----------------------------------------+
| 
|                               |
| 
|
+-----------------------------------------...| 
|                     IPFIX exported packet
| 
|                               |
| 
| +-----------------------------+----------------------------------------+
| 
| |                        Transport  Protocol                           |
| 
| +-----------------------------+----------------------------------------+
| 
|                               |
| 
+-------------------------------+-------------------------------------------
-+ 
                                | 
                                v 
                        IPFIX export packet to collector. 


(*) indicates that the block is optional. 


Thanks 
Ganesh 
  
 


------_=_NextPart_001_01C33073.DCC4E790
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4915.500" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=656344723-11062003><FONT face=Arial color=#0000ff 
size=2>Ganesh,</FONT></SPAN></DIV>
<DIV><SPAN class=656344723-11062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=656344723-11062003><FONT face=Arial color=#0000ff size=2>&nbsp; 
The use of templates overall is a protocol decision, keep in mind that other 
candidates, such as Diameter are not template oriented.&nbsp; So, from an 
architecture perspective, I guess templates should not be mentioned at all, they 
are strictly an artifact of the protocol.</FONT></SPAN></DIV>
<DIV><SPAN class=656344723-11062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=656344723-11062003><FONT face=Arial color=#0000ff size=2>&nbsp; 
I don't think I follow your point regarding the second item, "rules for 
encoding".&nbsp; Is anonymization an example of encoding, or simple translation 
of formats (e.g. ipaddr -&gt; string)?&nbsp; In either case, this sounds more 
protocol'ish than architecture.</FONT></SPAN></DIV>
<DIV><SPAN class=656344723-11062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=656344723-11062003><FONT face=Arial color=#0000ff size=2>-- 
Jeff</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Ganesh Sadasivan 
  [mailto:gsadasiv@cisco.com]<BR><B>Sent:</B> Wednesday, June 11, 2003 2:41 
  PM<BR><B>To:</B> MEYER,JEFFREY D (HP-Cupertino,ex1)<BR><B>Cc:</B> 
  ipfix@net.doit.wisc.edu<BR><B>Subject:</B> Re: [ipfix] IPFIX-ARCH : Functional 
  flow diagram.<BR><BR></FONT></DIV>Jeff, 
  <P>&nbsp;&nbsp; - Regarding <BR>&nbsp;&nbsp; "P<TT>icking &amp; sending data 
  records and corresponding templates "</TT> <BR>&nbsp;&nbsp; I&nbsp; separated 
  this out because the arch. spec does not dictate the rules for sending 
  <BR>&nbsp;&nbsp; templates &amp; corresponding data. That is more of a 
  protocol decision. 
  <P>&nbsp;&nbsp; -Regarding "<FONT face=Arial><FONT color=#000000><FONT 
  size=-1>rules for encoding"</FONT></FONT></FONT> <BR><FONT color=#000000><FONT 
  face=Arial><FONT size=-1>&nbsp;&nbsp; </FONT></FONT>The kind of information I 
  was thinking is if some one want to use more refined encoding</FONT> <BR><FONT 
  color=#000000>&nbsp;&nbsp; Eg. If the flow collection is done on IP address, 
  but the address itself is encoded as</FONT> <BR><FONT 
  color=#000000>&nbsp;&nbsp; a "aa.bb.cc.dd" string.</FONT> <BR><FONT 
  color=#000000>&nbsp;&nbsp; Is this something we should be allowing to be 
  supported (as a MAY) ?</FONT><FONT face=Arial><FONT color=#000000><FONT 
  size=-1></FONT></FONT></FONT> 
  <P><FONT face=Arial><FONT color=#000000><FONT 
  size=-1>Thanks</FONT></FONT></FONT> <BR><FONT face=Arial><FONT 
  color=#000000><FONT size=-1>Ganesh</FONT></FONT></FONT> <BR>&nbsp; <BR>&nbsp; 
  <BR>&nbsp; 
  <P>"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote: 
  <BLOCKQUOTE TYPE="CITE">&nbsp;<SPAN class=046484219-11062003><FONT 
    face=Arial><FONT color=#0000ff><FONT 
    size=-1>Ganesh,</FONT></FONT></FONT></SPAN><SPAN 
    class=046484219-11062003></SPAN><SPAN class=046484219-11062003><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>&nbsp;&nbsp; Nice 
    diagram.&nbsp; Maybe someday IETF will move beyond ASCII art...&nbsp; But 
    this is a fine example.</FONT></FONT></FONT></SPAN><SPAN 
    class=046484219-11062003></SPAN><SPAN class=046484219-11062003><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>&nbsp;&nbsp; In the exporter 
    block I would make a few modifications:</FONT></FONT></FONT></SPAN><SPAN 
    class=046484219-11062003></SPAN><SPAN class=046484219-11062003><FONT 
    face="Courier New">| || Rules 
    for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp; 
    |Functions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    ||&nbsp;&nbsp; |</FONT> <BR><TT>| 
    ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp; |- Packetize selected control&nbsp;&nbsp; ||&nbsp;&nbsp; |</TT> 
    <BR><TT>| || - Picking &amp; sending&nbsp;</SPAN><SPAN 
    class=046484219-11062003>data records|-&gt;|&nbsp; &amp; data information 
    into&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp; |</TT> <BR><TT>| 
    ||&nbsp;&nbsp;&nbsp; and corresponding templates&nbsp; |&nbsp; |&nbsp; IPFIX 
    export packet.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||...|</TT> 
    <BR><TT>| || - Timing out 
    flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp; |- Handle export 
    errors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp; |</TT> 
    <BR><TT>| || - Selecting flows for export(*) |&nbsp; |- Handle timeouts 
    &amp; overloads&nbsp; ||&nbsp;&nbsp; |</TT></SPAN><SPAN 
    class=046484219-11062003></SPAN><SPAN class=046484219-11062003><FONT 
    face="Courier New"> </FONT><FONT face=Arial><FONT color=#0000ff><FONT 
    size=-1>Specifically the data record and template selections are not 
    independent.&nbsp; You cannot send out a data record w/o sending a 
    template.&nbsp; There is no reason to send a template if you will never send 
    a data record of that form.&nbsp; So, I'd merge these into one bullet 
    point.</FONT></FONT></FONT> 
    <BLOCKQUOTE dir=ltr 
    style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
      <DIV class=OutlookMessageHeader dir=ltr><SPAN 
      class=046484219-11062003><FONT face=Arial><FONT color=#0000ff><FONT 
      size=-1>&nbsp; I removed the " " since the function already states 
      "packetize control and data into export packets".&nbsp; The rules seem to 
      imply a level of configurability of encoding which I don't think 
      exists.</FONT></FONT></FONT></SPAN><SPAN 
      class=046484219-11062003></SPAN><SPAN class=046484219-11062003><FONT 
      face=Arial><FONT color=#0000ff><FONT 
      size=-1>Regards,</FONT></FONT></FONT></SPAN><SPAN 
      class=046484219-11062003></SPAN><SPAN class=046484219-11062003><FONT 
      face=Arial><FONT color=#0000ff><FONT size=-1>&nbsp; Jeff 
      Meyer</FONT></FONT></FONT>&nbsp;</SPAN><FONT size=-1></FONT> 
      <P><FONT face=Tahoma><FONT size=-1>-----Original 
      Message-----</FONT></FONT> <BR><FONT face=Tahoma><FONT 
      size=-1><B>From:</B> Ganesh Sadasivan [<A 
      href="mailto:gsadasiv@cisco.com">mailto:gsadasiv@cisco.com</A>]</FONT></FONT> 
      <BR><FONT face=Tahoma><FONT size=-1><B>Sent:</B> Wednesday, June 11, 2003 
      11:58 AM</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>To:</B> 
      ipfix@net.doit.wisc.edu</FONT></FONT> <BR><FONT face=Tahoma><FONT 
      size=-1><B>Subject:</B> [ipfix] IPFIX-ARCH : Functional flow 
      diagram.</FONT></FONT> <BR>&nbsp;</P></DIV><TT>Hi,</TT> 
      <BR><TT>&nbsp;&nbsp; I want to add this figure into the architecture spec. 
      Please go through this send</TT> <BR><TT>&nbsp;&nbsp; send any 
      comments/corrections.</TT> 
      <P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Packet(s) coming into Observation Point(s)</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      v</TT> <BR><TT>&nbsp; 
      +-----------------+-------------------------+&nbsp;&nbsp; 
      +-----+------+</TT> <BR><TT>&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Metering 
      Process on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Observation 
      Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp; |&nbsp; packet header 
      capturing&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp; | Metering&nbsp;&nbsp; |</TT> <BR><TT>&nbsp; 
      |&nbsp;&nbsp;&nbsp; 
      timestamping&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp; | Process&nbsp;&nbsp;&nbsp; |</TT> <BR><TT>&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp; | on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> <BR><TT>&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp; | Observation|</TT> <BR><TT>&nbsp; |&nbsp; 
      +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp; | Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> <BR><TT>&nbsp; 
      |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp; |&nbsp; |&nbsp;&nbsp; sampling Si (1:1 in case of 
      no&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      sampling)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp; |&nbsp; | classifying Fi (NULL when No criteria) 
      |&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp; |&nbsp; 
      +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp; +---------+---------------------------------+&nbsp;&nbsp; 
      +-----+------+</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Flows (identified by observation domain)&nbsp;&nbsp;&nbsp; Flows</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      +----...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      +--------+...</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      v</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp; 
      +-------------------------------------+----------------+</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Flow Recording 
      Process(*)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp; | 
      +----------------------+&nbsp;&nbsp;&nbsp;&nbsp; 
      +------------------+&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp; | | Flow data 
      base&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&lt;----|Provide non-flow&nbsp; 
      |&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp; | | (includes 
      flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; | 
      information (Eg. |&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp; | | from all 
      obs.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; | 
      router state)&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp; | | points in an obs.&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp; +------------------+&nbsp;&nbsp;&nbsp; 
      |.....</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp; | | 
      domain)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp; | 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp; +------------------+&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp; | 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&lt;----|Maintain aggregate|&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp; | 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp; | statistics&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp; | 
      +----------------------+&nbsp;&nbsp;&nbsp;&nbsp; 
      +------------------+&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp; 
      +-------------------------------+----------------------+</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flow Database (identified by 
      observation domain)</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      +------------------------....</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      v</TT> 
      <BR><TT>+-----------+-------------------------------------+--------------------------+</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Export 
      Process&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      +----------------------... |</TT> <BR><TT>| 
      +---------+------------------------------------------------------------+&nbsp;&nbsp; 
      |</TT> <BR><TT>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      IPFIX 
      Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp; |</TT> <BR><TT>| |+---------------------------------+&nbsp; 
      +-------------------------------+|&nbsp;&nbsp; |</TT> <BR><TT>| || Rules 
      for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp; 
      |Functions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      ||&nbsp;&nbsp; |</TT> <BR><TT>| || - Picking &amp; sending 
      templates&nbsp;&nbsp; |&nbsp; |- Packetize selected control&nbsp;&nbsp; 
      ||&nbsp;&nbsp; |</TT> <BR><TT>| || - Picking &amp; sending data 
      records|-&gt;|&nbsp; &amp; data information 
      into&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp; |</TT> <BR><TT>| || - 
      Timing out 
      flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp; |&nbsp; IPFIX export 
      packet.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||...|</TT> 
      <BR><TT>| || - Encoding template &amp; data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp; |- Handle export 
      errors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp; 
      |</TT> <BR><TT>| || - Selecting flows for export(*) |&nbsp; |- Handle 
      timeouts &amp; overloads&nbsp; ||&nbsp;&nbsp; |</TT> <BR><TT>| 
      |+---------------------------------+&nbsp; 
      +-------------------------------+|&nbsp;&nbsp; |</TT> <BR><TT>| 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp; |</TT> <BR><TT>| 
      +-----------------------------+----------------------------------------+&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      +-----------------------------------------...|</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      IPFIX exported 
      packet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> <BR><TT>| 
      +-----------------------------+----------------------------------------+&nbsp;&nbsp; 
      |</TT> <BR><TT>| 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Transport&nbsp; 
      Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp; |</TT> <BR><TT>| 
      +-----------------------------+----------------------------------------+&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>+-------------------------------+--------------------------------------------+</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      v</TT> 
      <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      IPFIX export packet to collector.</TT> 
      <P><TT>(*) indicates that the block is optional.</TT> 
      <P><TT>Thanks</TT> <BR><TT>Ganesh</TT> <BR>&nbsp; 
  <BR>&nbsp;</P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></SPAN></BODY></HTML>

------_=_NextPart_001_01C33073.DCC4E790--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 12 01:01:34 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14883
	for <ipfix-archive@lists.ietf.org>; Thu, 12 Jun 2003 01:01:34 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QK2U-0005sM-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 23:50:18 -0500
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19QK2T-0005sE-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 23:50:17 -0500
Received: from Givoly ([192.168.0.3])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h5C4vVW26662;
	Wed, 11 Jun 2003 21:57:31 -0700
From: "Tal Givoly" <givoly@xacct.com>
To: "Juergen Quittek" <quittek@ccrle.nec.de>, <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] IPFIX requirements - final list of issues
Date: Wed, 11 Jun 2003 21:49:59 -0700
Message-ID: <DLEIIIOHMNPJPNMKGEFDGEGIDKAA.givoly@xacct.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 IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <28250421.1054662604@[10.1.1.128]>
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Juergen,

Typos in 11: amonst -> amongst; reqirements -> requirements.

I am not in favor of the notion to excluding usage-based accounting as an
application of this protocol (in the manner suggested in #11), but if that's
the decree, the industry would eventually have to come up with an
alternative method for this accounting data to be reported. It would be a
shame that it wouldn't be possible to leverage this protocol for all of
these applications. Obviously, some applications (including cases of
usage-based accounting) would suffice with this level of reliability.

Tal


-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Juergen Quittek
Sent: Tuesday, June 03, 2003 8:50 AM
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] IPFIX requirements - final list of issues


Dear all,

Attached you will find the list of proposed changes from version -09 to
version -10 of the IPFIX requirements. Benoit and I compiled it and
added some new wordings where required. Most things are already agreed
on the list, but please have a look at issues #5, #11, #12 and #13.

If there are no objections by Thursday,
I will post a new version on Friday.

Cheers,

    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  Thu Jun 12 01:05:05 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14928
	for <ipfix-archive@lists.ietf.org>; Thu, 12 Jun 2003 01:05:04 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QK2T-0005sC-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 23:50:17 -0500
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19QK2R-0005s4-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 23:50:16 -0500
Received: from Givoly ([192.168.0.3])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h5C4vRW26658;
	Wed, 11 Jun 2003 21:57:27 -0700
From: "Tal Givoly" <givoly@xacct.com>
To: "MEYER,JEFFREY D \(HP-Cupertino,ex1\)" <jeff.meyer2@hp.com>,
        "'Benoit Claise'" <bclaise@cisco.com>
Cc: "Mark Fullmer" <maf@eng.oar.net>, <calato@riverstonenet.com>,
        <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] drawing the line between protocol and data model document
Date: Wed, 11 Jun 2003 21:49:55 -0700
Message-ID: <DLEIIIOHMNPJPNMKGEFDEEGIDKAA.givoly@xacct.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0191_01C33063.65560E60"
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 V6.00.2600.0000
Importance: Normal
In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A502960069@xsun01.ptp.hp.com>
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.

------=_NextPart_000_0191_01C33063.65560E60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Benoit,

I agree with Jeff. I would add that, no more than 2 options should be
available for bytes/packet counters (32/64-bit unsigned integers).

But I would consider offering only a 64-bit value for byte counters. From
SNMP we learned that 32-bit byte counters cause countless problems. Since
IPFIX byte counters may be a result of aggregates, with today's networks it
is very feasible to overflow the 32-bit integer container.

Tal
  -----Original Message-----
  From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of MEYER,JEFFREY D (HP-Cupertino,ex1)
  Sent: Wednesday, June 11, 2003 10:00 AM
  To: 'Benoit Claise'
  Cc: Mark Fullmer; calato@riverstonenet.com; ipfix@net.doit.wisc.edu
  Subject: RE: [ipfix] drawing the line between protocol and data model
document


  Hi,

    >From a practical perspective, simply saying that a field is numeric and
may be encoded as 1 or 100 bytes seems like it puts an unnecessary and
unjustified burden on the collector, or any other app which might want to
handle this data.

    Is there some particular reason why saying a specific information item,
e.g. numBytes, is a 32-bit integer or a 64-bit integer is considered
undesireable.  It certainly seems like the developer of a consuming
application would benefit from knowing how to target variables in their
application for given information items.  I guess one could assume that
everything will fit in a 64-bit integer and code your app that way, but
again, this seems like an unnecessary burden for unclear gains.

    I don't think anything needs to change in the protocol.  Simply a more
constrained approach to dealing with numeric fields with explicit types.

  Regards,

    Jeff Meyer
    -----Original Message-----
    From: Benoit Claise [mailto:bclaise@cisco.com]
    Sent: Wednesday, June 11, 2003 4:31 AM
    To: Benoit Claise
    Cc: Mark Fullmer; calato@riverstonenet.com; ipfix@net.doit.wisc.edu
    Subject: Re: [ipfix] drawing the line between protocol and data model
document


    Dear all,

      Mark,
On Thu, May 01, 2003 at 10:51:49AM -0400, calato@riverstonenet.com wrote:

<snip>


The richness of the protocol encoding specification is another
matter. The protocol would reference each element in the data
model and define exaclty how that element is encoded. In the above
example, the protocol is free to encode that as an unsigned byte
if the value is < 256.


The ramifications of doing this with a template based system are a bit
ugly.  Consider a flow with just 2 counters -- octets, packets.
Each could have a 1 to 8 byte encoding.  That's a potential of 64
different templates for representing 1 type of flow.

This (at first glance) looks like it adds considerable cycles to the
encode / decode process to save a few bytes in the transport.

The current v9 spec appears to allow this, but only for IN_BYTES and
IN_PKTS.


                                          counter with length
   IN_BYTES                 1       N     N x 8 bits for bytes
                                          associated with an IP Flow


Is this true?  Benoit?

      I'm trying to catch up with my IPIFX emails; I know I'm late on this
thread, which seems to have reached consensus as far as I can tell, but as
this is a direct question to me, let me answer.
      Actually, there are:
      BYTES            1             4             field type for the 32 bit
bytes counter
      BYTES_64      23           8             field type for the 64 bit
bytes counter
    Let me reply to my own email because, after speaking to different
people, I have to correct what I said.
    We actually do:

                                          Incoming counter with length
   IN_BYTES                 1       N     N x 8 bits for bytes
                                          associated with an IP Flow

                                          Incoming counter with length
   IN_PKTS		    2       N     N x 8 bits for packets
                                          associated with an IP Flow

And no BYTES_64 is defined.

Regards, Benoit.




      So the draft that you refer to needs a quick update.
      <!--[endif]-->
      Regards, Benoit




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/






------=_NextPart_000_0191_01C33063.65560E60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2722.900" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D768200504-12062003><FONT face=3DArial color=3D#0000ff =

size=3D2>Benoit,</FONT></SPAN></DIV>
<DIV><SPAN class=3D768200504-12062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D768200504-12062003><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2>I agree with Jeff. I would add that<SPAN =
class=3D768200504-12062003>, no=20
more than&nbsp;2 options should be available for bytes/packet counters=20
(32/64-bit unsigned integers).</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>But I would consider=20
offering&nbsp;<SPAN class=3D768200504-12062003><STRONG>only</STRONG> =
</SPAN>a=20
64-bit value for byte counters. From SNMP we learned that 32-bit byte =
counters=20
cause countless problems. Since IPFIX byte counters may be a result of=20
aggregates, with today's networks it is very feasible to overflow the =
32-bit=20
integer container.</FONT></SPAN></DIV>
<DIV><SPAN class=3D768200504-12062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D768200504-12062003><FONT face=3DArial color=3D#0000ff =

size=3D2>Tal</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> majordomo =
listserver=20
  [mailto:majordomo@mil.doit.wisc.edu]<B>On Behalf Of </B>MEYER,JEFFREY =
D=20
  (HP-Cupertino,ex1)<BR><B>Sent:</B> Wednesday, June 11, 2003 10:00=20
  AM<BR><B>To:</B> 'Benoit Claise'<BR><B>Cc:</B> Mark Fullmer;=20
  calato@riverstonenet.com; ipfix@net.doit.wisc.edu<BR><B>Subject:</B> =
RE:=20
  [ipfix] drawing the line between protocol and data model=20
  document<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Hi,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp; &gt;From a practical perspective, simply saying that a =
field is=20
  numeric and may be encoded as 1 or 100 bytes seems like it puts an =
unnecessary=20
  and unjustified burden on the collector, or any other app which might =
want to=20
  handle this data.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp; Is there some particular reason why saying a specific=20
  information item, e.g. numBytes, is a 32-bit integer or a 64-bit =
integer is=20
  considered undesireable.&nbsp; It certainly seems like the developer =
of a=20
  consuming application would benefit from knowing how to target =
variables in=20
  their application for given information items.&nbsp; I guess one could =
assume=20
  that everything will fit in a 64-bit integer and code your app that =
way, but=20
  again, this seems like an unnecessary burden for unclear=20
  gains.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp; I don't think anything needs to change in the =
protocol.&nbsp;=20
  Simply a more constrained approach to dealing with numeric fields with =

  explicit types.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Regards,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D718225916-11062003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2><BR>&nbsp; Jeff Meyer</FONT></SPAN></DIV>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Benoit Claise=20
    [mailto:bclaise@cisco.com]<BR><B>Sent:</B> Wednesday, June 11, 2003 =
4:31=20
    AM<BR><B>To:</B> Benoit Claise<BR><B>Cc:</B> Mark Fullmer;=20
    calato@riverstonenet.com; ipfix@net.doit.wisc.edu<BR><B>Subject:</B> =
Re:=20
    [ipfix] drawing the line between protocol and data model=20
    document<BR><BR></FONT></DIV>Dear all,<BR>
    <BLOCKQUOTE cite=3Dmid3EDCB48D.40207@cisco.com type=3D"cite">Mark,=20
      <BLOCKQUOTE cite=3Dmid20030501162116.B33173@net.ohio-state.edu =
type=3D"cite"><PRE wrap=3D"">On Thu, May 01, 2003 at 10:51:49AM -0400, =
<A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:calato@riverstonenet.com">calato@riverstonenet.com</A> =
wrote:

&lt;snip&gt;

  </PRE>
        <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">The richness of the =
protocol encoding specification is another
matter. The protocol would reference each element in the data
model and define exaclty how that element is encoded. In the above=20
example, the protocol is free to encode that as an unsigned byte=20
if the value is &lt; 256.=20
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
The ramifications of doing this with a template based system are a bit
ugly.  Consider a flow with just 2 counters -- octets, packets.
Each could have a 1 to 8 byte encoding.  That's a potential of 64
different templates for representing 1 type of flow.

This (at first glance) looks like it adds considerable cycles to the
encode / decode process to save a few bytes in the transport.

The current v9 spec appears to allow this, but only for IN_BYTES and
IN_PKTS.

  </PRE>
        <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">                        =
                  counter with length
   IN_BYTES                 1       N     N x 8 bits for bytes
                                          associated with an IP Flow
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
Is this true?  Benoit?
  </PRE></BLOCKQUOTE>I'm trying to catch up with my IPIFX emails; I know =

      I'm late on this thread, which seems to have reached consensus as =
far as I=20
      can tell, but as this is a direct question to me, let me=20
      answer.<BR>Actually, there are:<BR>BYTES&nbsp; &nbsp;&nbsp; =
&nbsp;&nbsp;=20
      &nbsp; &nbsp; 1 &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; =
&nbsp;&nbsp; 4=20
      &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; field type for =
the 32=20
      bit bytes counter<BR>BYTES_64&nbsp;&nbsp; &nbsp;&nbsp; =
23&nbsp;&nbsp;=20
      &nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;=20
      =
8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
      field type for the 64 bit bytes counter</BLOCKQUOTE>Let me reply =
to my own=20
    email because, after speaking to different people, I have to correct =
what I=20
    said.<BR>We actually do:<BR><PRE wrap=3D"">                          =
                Incoming counter with length
   IN_BYTES                 1       N     N x 8 bits for bytes
                                          associated with an IP Flow

                                          Incoming counter with length
   IN_PKTS		    2       N     N x 8 bits for packets
                                          associated with an IP Flow

And no BYTES_64 is defined.

Regards, Benoit.

<SPAN lang=3DEN-US style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman'"><SPAN></SPAN><SPAN></SPAN></SPAN></PRE>
    <BLOCKQUOTE cite=3Dmid3EDCB48D.40207@cisco.com =
type=3D"cite"><BR><BR>So the=20
      draft that you refer to needs a quick=20
      update.<BR>&lt;!--[endif]--&gt;<O:IDMAP v:ext=3D"edit"=20
      data=3D"3"></O:IDMAP><BR>Regards, Benoit<BR><BR><BR><BR>
      <BLOCKQUOTE cite=3Dmid20030501162116.B33173@net.ohio-state.edu =
type=3D"cite"><PRE wrap=3D"">mark

--
Help        <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A> and say "help<A class=3Dmoz-txt-link-rfc2396E =
href=3D"inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay"=
>" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"</A>unsubscribe ipfix" in message body
Archive     <A class=3Dmoz-txt-link-freetext =
href=3D"http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/a=
rchive/</A>
  =
</PRE></BLOCKQUOTE><BR></BLOCKQUOTE><BR></BLOCKQUOTE></BLOCKQUOTE></BODY>=
</HTML>

------=_NextPart_000_0191_01C33063.65560E60--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 12 01:05:51 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14990
	for <ipfix-archive@lists.ietf.org>; Thu, 12 Jun 2003 01:05:50 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QK2R-0005s1-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 11 Jun 2003 23:50:15 -0500
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19QK2P-0005rr-00
	for ipfix@net.doit.wisc.edu; Wed, 11 Jun 2003 23:50:13 -0500
Received: from Givoly ([192.168.0.3])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h5C4vPW26654;
	Wed, 11 Jun 2003 21:57:26 -0700
From: "Tal Givoly" <givoly@xacct.com>
To: "Ganesh Sadasivan" <gsadasiv@cisco.com>, <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] IPFIX-ARCH : Functional flow diagram.
Date: Wed, 11 Jun 2003 21:49:53 -0700
Message-ID: <DLEIIIOHMNPJPNMKGEFDCEGIDKAA.givoly@xacct.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_018D_01C33063.6450D360"
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 V6.00.2600.0000
Importance: Normal
In-Reply-To: <3EE77BCC.FF358FB8@cisco.com>
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.

------=_NextPart_000_018D_01C33063.6450D360
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Ganesh,

Usually, diagrams are useful for illustration of concepts, but aren't ideal
for specification. If you would like this to be a specification of the inner
workings of the metering process and exporting process, I would recommend
you add the following:
- Identification of all modules and interconnects
- Text that describes each of these modules and interconnects to
disambiguate it for the reader.

Regarding the content itself - I believe aggregation is not clear. Also
annonymization location isn't clear.

It seems to me to make more sense to have two distinct diagrams - one at the
high level showing MP (many to 1) -> EP. Then it would be possible to blow
up the MP and the EP independently and discuss them independently. The EP
depends primarily on the protocol features while the MP would have the
support for most of the capabilities such as timestamping, and others that
you discuss.

Tal
-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of
Ganesh Sadasivan
Sent: Wednesday, June 11, 2003 11:58 AM
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] IPFIX-ARCH : Functional flow diagram.


  Hi,
     I want to add this figure into the architecture spec. Please go through
this send
     send any comments/corrections.

                      Packet(s) coming into Observation Point(s)
                      |                                   |
                      |                                   |
                      v                                   v
    +-----------------+-------------------------+   +-----+------+
    |           Metering Process on an          |   |            |
    |              Observation Point            |   |            |
    |  packet header capturing                  |   |            |
    |         |                                 |   | Metering   |
    |    timestamping                           |   | Process    |
    |         |                                 |   | on an      |
    |         v                                 |   | Observation|
    |  +------+                                 |   | Point      |
    |  |      |                                 |   |            |
    |  |   sampling Si (1:1 in case of no       |   |            |
    |  |      |          sampling)              |   |            |
    |  | classifying Fi (NULL when No criteria) |   |            |
    |  |      |                                 |   |            |
    |  +------+                                 |   |            |
    |         |                                 |   |            |
    +---------+---------------------------------+   +-----+------+
              |                                           |
            Flows (identified by observation domain)    Flows
              +----...                                    +--------+...
              |                                           v
              |     +-------------------------------------+----------------+
              |     |             Flow Recording Process(*)                |
              |     | +----------------------+     +------------------+    |
              |     | | Flow data base       |<----|Provide non-flow  |    |
              |     | | (includes flows      |     | information (Eg. |    |
              |     | | from all obs.        |     | router state)    |    |
              |     | | points in an obs.    |     +------------------+
|.....
              |     | | domain)              |                             |
              |     | |                      |     +------------------+    |
              |     | |                      |<----|Maintain aggregate|    |
              |     | |                      |     | statistics       |    |
              |     | +----------------------+     +------------------+    |
              |     +-------------------------------+----------------------+
              |                                     |
              |        Flow Database (identified by observation domain)
              |
+------------------------....
              v                                     v

+-----------+-------------------------------------+-------------------------
-+
  |           |            Export Process           |
|
  |           |
+----------------------... |
  | +---------+------------------------------------------------------------+
|
  | |         v                  IPFIX Protocol                            |
|
  | |+---------------------------------+  +-------------------------------+|
|
  | || Rules for                       |  |Functions                      ||
|
  | || - Picking & sending templates   |  |- Packetize selected control   ||
|
  | || - Picking & sending data records|->|  & data information into      ||
|
  | || - Timing out flows              |  |  IPFIX export packet.
||...|
  | || - Encoding template & data      |  |- Handle export errors         ||
|
  | || - Selecting flows for export(*) |  |- Handle timeouts & overloads  ||
|
  | |+---------------------------------+  +-------------------------------+|
|
  | |                                                                      |
|
  | +-----------------------------+----------------------------------------+
|
  |                               |
|
  |
+-----------------------------------------...|
  |                     IPFIX exported packet
|
  |                               |
|
  | +-----------------------------+----------------------------------------+
|
  | |                        Transport  Protocol                           |
|
  | +-----------------------------+----------------------------------------+
|
  |                               |
|

+-------------------------------+-------------------------------------------
-+
                                  |
                                  v
                          IPFIX export packet to collector.
  (*) indicates that the block is optional.

  Thanks
  Ganesh




------=_NextPart_000_018D_01C33063.6450D360
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2722.900" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D796145803-12062003><FONT face=3DArial color=3D#0000ff =

size=3D2>Ganesh,</FONT></SPAN></DIV>
<DIV><SPAN class=3D796145803-12062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D796145803-12062003><FONT face=3DArial color=3D#0000ff =

size=3D2>Usually, diagrams are useful for illustration of concepts, but =
aren't=20
ideal for specification. If you would like this to be a specification of =
the=20
inner workings of the metering process and exporting process, I would =
recommend=20
you add the following:</FONT></SPAN></DIV>
<DIV><SPAN class=3D796145803-12062003><FONT face=3DArial color=3D#0000ff =
size=3D2>-=20
Identification of all modules and interconnects</FONT></SPAN></DIV>
<DIV><SPAN class=3D796145803-12062003><FONT face=3DArial color=3D#0000ff =
size=3D2>- Text=20
that describes each of these modules and interconnects to disambiguate =
it for=20
the reader.</FONT></SPAN></DIV>
<DIV><SPAN class=3D796145803-12062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D796145803-12062003><FONT face=3DArial color=3D#0000ff =

size=3D2>Regarding the content itself - I believe aggregation is not =
clear. Also=20
annonymization location isn't clear.</FONT></SPAN></DIV>
<DIV><SPAN class=3D796145803-12062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D796145803-12062003><FONT face=3DArial color=3D#0000ff =
size=3D2>It=20
seems to me to make more sense to have two distinct diagrams - one at =
the high=20
level showing&nbsp;MP&nbsp;(many to 1) -&gt; EP. Then&nbsp;it would be =
possible=20
to blow up the MP and the EP independently and discuss them =
independently. The=20
EP depends primarily on the protocol features while the MP =
would&nbsp;have the=20
support for most of the capabilities such as timestamping, and others =
that you=20
discuss.</FONT></SPAN></DIV>
<DIV><SPAN class=3D796145803-12062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D796145803-12062003><FONT face=3DArial color=3D#0000ff =

size=3D2>Tal</FONT></SPAN></DIV>
<DIV><SPAN class=3D796145803-12062003></SPAN><FONT face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> majordomo listserver =

[mailto:majordomo@mil.doit.wisc.edu]<B>On Behalf Of </B>Ganesh=20
Sadasivan<BR><B>Sent:</B> Wednesday, June 11, 2003 11:58 =
AM<BR><B>To:</B>=20
ipfix@net.doit.wisc.edu<BR><B>Subject:</B> [ipfix] IPFIX-ARCH : =
Functional flow=20
diagram.<BR><BR></DIV></FONT>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"><TT>Hi,</TT>=20
  <BR><TT>&nbsp;&nbsp; I want to add this figure into the architecture =
spec.=20
  Please go through this send</TT> <BR><TT>&nbsp;&nbsp; send any=20
  comments/corrections.</TT>=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<TT></TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Packet(s) coming into Observation Point(s)</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  v</TT> <BR><TT>&nbsp;=20
  +-----------------+-------------------------+&nbsp;&nbsp; =
+-----+------+</TT>=20
  <BR><TT>&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Metering Process on =
an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
  Observation=20
  =
Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; |&nbsp; packet header=20
  =
capturing&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; | Metering&nbsp;&nbsp; |</TT> <BR><TT>&nbsp; =
|&nbsp;&nbsp;&nbsp;=20
  =
timestamping&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; | Process&nbsp;&nbsp;&nbsp; |</TT> <BR><TT>&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; | on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> =
<BR><TT>&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; | Observation|</TT> <BR><TT>&nbsp; |&nbsp;=20
  =
+------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; | Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> =
<BR><TT>&nbsp;=20
  |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; |&nbsp; |&nbsp;&nbsp; sampling Si (1:1 in case of=20
  no&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
sampling)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; |&nbsp; | classifying Fi (NULL when No criteria) =
|&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; |&nbsp;=20
  =
+------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
  <BR><TT>&nbsp; =
+---------+---------------------------------+&nbsp;&nbsp;=20
  +-----+------+</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Flows=20
  (identified by observation domain)&nbsp;&nbsp;&nbsp; Flows</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  =
+----...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  +--------+...</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  v</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------------------------------------+----------------+</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Flow=20
  Recording=20
  =
Process(*)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | =
+----------------------+&nbsp;&nbsp;&nbsp;&nbsp;=20
  +------------------+&nbsp;&nbsp;&nbsp; |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | | Flow data=20
  base&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&lt;----|Provide =
non-flow&nbsp;=20
  |&nbsp;&nbsp;&nbsp; |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | | (includes =
flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | information (Eg. |&nbsp;&nbsp;&nbsp; =
|</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | | from all=20
  obs.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp; |=20
  router state)&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | | points in an obs.&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; +------------------+&nbsp;&nbsp;&nbsp; =
|.....</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | |=20
  =
domain)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; |=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; +------------------+&nbsp;&nbsp;&nbsp; =
|</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; |=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&lt;----|Maintain aggregate|&nbsp;&nbsp;&nbsp; |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; |=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | =
statistics&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp; |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  |&nbsp;&nbsp;&nbsp;&nbsp; | =
+----------------------+&nbsp;&nbsp;&nbsp;&nbsp;=20
  +------------------+&nbsp;&nbsp;&nbsp; |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------------------------------+----------------------+</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flow Database (identified =
by=20
  observation domain)</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +------------------------....</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
  =
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  v</TT>=20
  =
<BR><TT>+-----------+-------------------------------------+--------------=
------------+</TT>=20
  <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Export=20
  Process&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
  |</TT> =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +----------------------... |</TT> <BR><TT>|=20
  =
+---------+------------------------------------------------------------+&=
nbsp;&nbsp;=20
  |</TT> <BR><TT>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  IPFIX=20
  =
Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; |</TT> <BR><TT>| =
|+---------------------------------+&nbsp;=20
  +-------------------------------+|&nbsp;&nbsp; |</TT> <BR><TT>| || =
Rules=20
  =
for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;=20
  =
|Functions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  ||&nbsp;&nbsp; |</TT> <BR><TT>| || - Picking &amp; sending=20
  templates&nbsp;&nbsp; |&nbsp; |- Packetize selected =
control&nbsp;&nbsp;=20
  ||&nbsp;&nbsp; |</TT> <BR><TT>| || - Picking &amp; sending data=20
  records|-&gt;|&nbsp; &amp; data information =
into&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  ||&nbsp;&nbsp; |</TT> <BR><TT>| || - Timing out=20
  =
flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
  |&nbsp; |&nbsp; IPFIX export=20
  packet.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||...|</TT> =
<BR><TT>|=20
  || - Encoding template &amp; data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp; |-=20
  Handle export errors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  ||&nbsp;&nbsp; |</TT> <BR><TT>| || - Selecting flows for export(*) =
|&nbsp; |-=20
  Handle timeouts &amp; overloads&nbsp; ||&nbsp;&nbsp; |</TT> <BR><TT>|=20
  |+---------------------------------+&nbsp;=20
  +-------------------------------+|&nbsp;&nbsp; |</TT> <BR><TT>|=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; |</TT> <BR><TT>|=20
  =
+-----------------------------+----------------------------------------+&=
nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-----------------------------------------...|</TT>=20
  =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  IPFIX exported=20
  =
packet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT> <BR><TT>|=20
  =
+-----------------------------+----------------------------------------+&=
nbsp;&nbsp;=20
  |</TT> <BR><TT>|=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Transport&nbsp;=20
  =
Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; |</TT> <BR><TT>|=20
  =
+-----------------------------+----------------------------------------+&=
nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>+-------------------------------+--------------------------------=
------------+</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  v</TT>=20
  =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
  IPFIX export packet to collector.</TT><TT></TT>=20
  <P><TT>(*) indicates that the block is optional.</TT><TT></TT>=20
  <P><TT>Thanks</TT> <BR><TT>Ganesh</TT> <BR><TT></TT>&nbsp; =
<BR><TT></TT>&nbsp;=20
  </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_018D_01C33063.6450D360--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 12 06:21:10 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02296
	for <ipfix-archive@lists.ietf.org>; Thu, 12 Jun 2003 06:21:09 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QOjf-00078f-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 12 Jun 2003 04:51:11 -0500
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 19QOje-00078R-00
	for ipfix@net.doit.wisc.edu; Thu, 12 Jun 2003 04:51:10 -0500
Received: from cisco.com (ams-clip-vpn-dhcp4289.cisco.com [10.61.80.192])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h5C9ofp21472;
	Thu, 12 Jun 2003 11:50:41 +0200 (CEST)
Message-ID: <3EE84CF0.4030207@cisco.com>
Date: Thu, 12 Jun 2003 11:50:40 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: Sebastian Zander <zander@fokus.fraunhofer.de>, ipfix@net.doit.wisc.edu
Subject: Scope: (was: Re: [ipfix] extensibility of the ipfix protocol)
References: <1D3D2C371FCBD947A7897FABBD3533A502960067@xsun01.ptp.hp.com>
In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A502960067@xsun01.ptp.hp.com>
Content-Type: multipart/alternative;
 boundary="------------050102070800090803000009"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.
--------------050102070800090803000009
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Jeff,

>  
>   So it sounds like "scope" is more or less a way to pack multiple 
> discrete records into a single template. 

I would say: to group multiple data types that belong to the same scope; 
the scope could be
               0x0001 System  
               0x0002 Interface 
               0x0003 Line Card 
               0x0004 Cache 
               0x0005 Template
For example (example section in the draft):
   - total number of Export Packets and total number of exported Flows 
exported by each line card
   So scope = line card, data types = Export Packets and Exported Flows

There was a previous discussion about exporting the number of flow 
records per template. This is also possible
So scope: = template, data type = Exported Flows

> This means that templates are no longer necessarily in first normal 
> form as some attributes may repeat.

Can you please elaborate.

>  
>   In general, I still think this is a lot of complexity to address a 
> use case which could be addressed with other mechanisms already 
> present in NFv9, i.e. treat all attributes as equals from the protocol 
> perspective, only have one template model, distinguish between "option 
> records" and "flow records".

Let me take 3 examples

1. I export flow data records composed of src IP address, dst IP 
address, Fragmented, number of packets, number of bytes
where Fragmented is just 0 or 1.
But the collecting process doesn't know about this Fragmented data type; 
it has got 2 choices.
- either it discards all the information because it doesn't understand 
one of the data types
- either it just sum up the number of packets and bytes per IP 
addresses, regardless of the Fragmented, to at least report something 
meaningfull. So a default action (summing up) is possible.

2. I export an options data record composed of scope =  line card X and 
data type = the sampling rate Y.
But the collecting process doesn't know about the the line card scope; 
it can't even take a default action because it doesn't know where to 
apply it to. The exporter doesn't know what to do with the sampling 
rate, even if it understands the sampling rate data type.

3. To follow up on the example 2, I export _flow _data records composed 
of  number of packets, number of bytes, input interface, line card, 
sampling rate, exported flows, template ID. So data types are equals.
Let's assume that the collecting process knows about all data types.
What should the sampling rate be applied to? Interface, line card, or 
template?
What should the export packet be applied to? Interface, line card, or 
template?

>  
>   Since I believe that the information transfer you describe can be 
> accomplished with fewer moving parts in the protocol, and since the 
> "simplicity" of netflow was cited as a key reason for its selection, 
> can we make this simplification?

Can we make this simplification? Well, as explained during the last IETF 
meeting, this new IPFIX protocol belongs to the IETF. So it will become 
what the WG consensus will decide it to be!
 
Nevertheless, I'm in favor of keeping the scope because of :
0. in flow data records, we don't always what is the scope
1. the scope is used as grouping factor (Sebastian's term)
2. with flow data record (without scope) we can take a default action
3. the scope is a more important data type to know about


Regards, Benoit.

>  
> Regards,
>  
>   Jeff Meyer
>
>     -----Original Message-----
>     *From:* Benoit Claise [mailto:bclaise@cisco.com]
>     *Sent:* Wednesday, June 11, 2003 4:35 AM
>     *To:* Sebastian Zander
>     *Cc:* MEYER,JEFFREY D (HP-Cupertino,ex1); ipfix@net.doit.wisc.edu
>     *Subject:* Re: [ipfix] extensibility of the ipfix protocol
>
>     Hi Jeff and Sebastian,
>
>>     Jeff,
>>
>>     comments below
>>
>>     MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>>
>>>     Sebastian,
>>>
>>>       I'd agree that making the extensibility model more explicit is
>>>     desireable.
>>>         I'm still unclear on when or why one would extend
>>>     information into the
>>>     header
>>>     vs. extending the data template sent itself.  I view the Option
>>>     template as
>>>     flagging "pseudo-flow records" which have a set of attributes
>>>     which carry
>>>     information other than actual flow details, e.g. configuration
>>>     info or
>>>     counters.
>>>
>>>       But isn't the combination of having Extensible Flow Records
>>>     (for "real"
>>>     data) and Extensible Option Records (for "other" data)
>>>     sufficient to move
>>>     any form of data the exporter wants to export?
>>>
>>>       I guess this is what Mark was saying.  So I'd agree to that.
>>
>>
>>     I also agree
>>
>>>       I would see the same "Information Model" and extension model
>>>     being used
>>>     for both Flow Record and Options.
>>>
>>>
>>>       So to clarify, the header is fixed.  There is a distinction
>>>     between flow
>>>     records and "other" data transmitted by the exporter.  And a
>>>     common way
>>>     of defining how attributes which appear in either flow or option
>>>     records
>>>     will be used.
>>>
>>>       I'm not sure on why the "Scope" options should be treated
>>>     differently
>>>     than any other attribute which may appear in an Option Record
>>>     (Section 6.1)
>>>     in NFv9 specification.  Seems like things would be simpler and
>>>     just as
>>>     effective if there were just a "Scope" attribute which could
>>>     appear in
>>>     Option records.  In this case an Options template would be
>>>     identical
>>>     to a Flow Template except it would have a FlowSet id of 1 vs. 0.
>>>
>>>       Does that work? 
>>
>     Jeff,
>     Yes it would work.
>     One argument for treating the scope differently is that the scope
>     must be applied to all options data records.
>     And the Scope is an important data type. If you don't know about
>     it, you can't apply the "action" that is associated with the
>     options flow record.
>     For example: if the scope is the line card X and the sampling rate
>     Y and if the collector doesn't know abouth the scope for the line
>     card, the exporter doesn't know that the number of bytes should be
>     multipled by the sampling rate.
>     Ok, that would be almost the same for an unknow data types in the
>     flow data record, but that one could just be reported, without
>     taking an "action"
>
>>>
>>
>>     I must admit that i don't 100% understand how scope is supposed
>>     to work.
>>     The example in 10.4 and 10.5 seems somewhat flawed. The draft
>>     says there are
>>     N scope fields and N option fields. Must the number of scope
>>     fields be equal
>>     to the number of option fields? If yes this seems to waste lots
>>     of space if the
>>     scope does not change (and it is not the case in the example). If
>>     not (probably
>>     the authors meant M and N) the question is how to map the scope
>>     fields to the
>>     options fields when there is more than 1 scope field (seems
>>     impossibe)? 
>
>     Sebastian, you are right that the intention is to have M and N.
>     This has been corrected in the latest draft.
>     How to map the scope fields to the options fields when there is
>     more than 1 scope field?
>     The scope can be limited further by listing multiple scopes which
>     all have to match at the same time.
>
>>
>>
>>     Making scope another attribute sounds somewhat good. However has
>>     scope some
>>     kind of grouping functionality 
>
>     Yes exactly. See the previous answer to Jeff
>
>>     or must it explicitly appear before each option?
>>     Can scopes be combined such as e.g. this option is per interface
>>     vs. this option
>>     is per template per interface?
>
>     Exactly.
>
>     Regards, Benoit.
>
>>     I think my questions are about grouping because
>>     scope seems to have some kind of grouping function...
>>
>>     Cheers,
>>
>>     Sebastian
>>
>>>
>>>     Regards,
>>>
>>>       Jeff Meyer
>>>
>>>     -----Original Message-----
>>>     From: Sebastian Zander [mailto:zander@fokus.fraunhofer.de]
>>>     Sent: Wednesday, May 21, 2003 5:19 PM
>>>     To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>>     Cc: ipfix@net.doit.wisc.edu
>>>     Subject: Re: [ipfix] extensibility of the ipfix protocol
>>>
>>>
>>>     Jeff,
>>>
>>>     MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>>>
>>>>     Sebastian,
>>>>
>>>>      One of the issues of talking about extensibility in the
>>>>     generic sense is
>>>>     that it creates the temptation to specify generality without
>>>>     any driving
>>>>     use case.  "Someone may want to ..." seems like a slippery
>>>>     slope in
>>>
>>>
>>>     bounding
>>>
>>>>     requirements.
>>>>
>>>>      In particular the case (1) extending fields in the header sounds
>>>
>>>
>>>     dubious.
>>>
>>>>      Since IPFIX is about getting flow records from the exporter to
>>>>     the
>>>>     collector,
>>>>     what is the purpose of allowing arbitrary header extensions?
>>>
>>>
>>>
>>>     The purpose is to send information per packet which is
>>>     associated to or
>>>     necessary for using the rest of the information contained in the
>>>     packet. For
>>>     me its pretty obvious that you need such an extension mechanism.
>>>     And as Mark
>>>     pointed out this is already supported by the use of option
>>>     templates.
>>>
>>>     netflow certainly meets the extensibility reqs but the netflow
>>>     drafts do
>>>     *not*
>>>     a good job IMO in explaining its extensibility compared to e.g.
>>>     what
>>>     Diameter
>>>     does. Instead of letting the reader guess the ipfix draft should
>>>     have more
>>>     verbage.
>>>
>>>
>>>>       In case (2), I'd certainly recommend option (b), making an
>>>>     explicit
>>>>     separation of namespaces (in this case integer values) by using
>>>>     unique
>>>>     vendor ids as independent "namespace authorities" seems like
>>>>     common sense.
>>>>     SNMP's been doing this for years, and Diameter is also
>>>>     following this
>>>>     convention as you point out.
>>>>
>>>>      As for case (3), my understanding is that explicit type
>>>>     information in
>>>>     the payload/template itself did not achieve consensus.   This
>>>>     does mean
>>>>     that the numeric id (and optional vendorId) needs some concept
>>>>     of type,
>>>>     in a supporting document.  Having each attribute specify its
>>>>     type by
>>>>     reference to a type space defined in the base IPFIX Information
>>>>     Model
>>>>     is the way to go here (in my opinion).
>>>
>>>
>>>
>>>     Yeah, but the protocol draft must be aligned somehow to the
>>>     information
>>>     model draft e.g. where are the types defined, where is the encoding
>>>     defined...
>>>
>>>     Cheers,
>>>
>>>     Sebastian
>>>
>>>
>>>>      When a vendor extends the set of attributes, chosing a well
>>>>     defined
>>>>     type would be preferred to inventing a new type.  If the vendor
>>>>     cannot
>>>>     resist the overwhelming temptation to create new types, it can
>>>>     be defined in their own information model.
>>>>
>>>>
>>>>     Regards,
>>>>
>>>>      Jeff Meyer
>>>>
>>>>     -----Original Message-----
>>>>     From: Sebastian Zander [mailto:zander@fokus.fraunhofer.de]
>>>>     Sent: Tuesday, May 06, 2003 6:55 PM
>>>>     To: ipfix@net.doit.wisc.edu
>>>>     Subject: [ipfix] extensibility of the ipfix protocol
>>>>
>>>>
>>>>     Hi,
>>>>
>>>>     although extensibility is mandatory by the requirements there
>>>>     hasn't
>>>>     been a lot discussion on how to do it and the chosen candidate
>>>>     protocol
>>>>     doesn't say much about extensibility. So here are my thoughts
>>>>     about
>>>>     extensibility.
>>>>
>>>>     The protocol specification must define how the protocol can be
>>>>     extended.
>>>>
>>>>     I see the following (but there may be more) ways of extending the
>>>>     protocol:
>>>>
>>>>     1. Extending the fixed packet header
>>>>     This would allow to add new header fields without changing the
>>>>     protocol specification.
>>>>
>>>>     A bit (X) could be stolen from version to indicate the presence of
>>>>     extension header(s). Extension header(s) follow the fixed
>>>>     header if
>>>>     X=1. Extension header(s) consists of type, length and value.
>>>>
>>>>     2. Extending the attribute/field space
>>>>     This is certainly needed. It could be done at least in two ways:
>>>>     a) A flat number space where numbers are specified in extension
>>>>        RFCs and registered by IANA. A nice thing would a dynamic
>>>>        space where numbers are not defined by IANA but could be
>>>>     negotiated
>>>>        out of band (see payload type in the RTP specification). Such a
>>>>        space could also be used as safe playground.
>>>>     b) A number space which is defined in extension RFCs (IANA) and
>>>>     the
>>>>        possibility of using vendor specific attributes by having an
>>>>     optional
>>>>        vendor ID field in the template specification. The vendor ID
>>>>     would
>>>>        be IANA assigned but the vendor then could use its private
>>>>     field ID
>>>>        space (see the Diameter Base protocol specification). Adds more
>>>>        complexity and overhead to the protocol but could be very
>>>>     useful
>>>>        when the protocol becomes widely adopted and a lot of
>>>>     extensions
>>>>        are done.
>>>>
>>>>     3. Extending the type space (if there are types at all)
>>>>     Probably there won't be much need to extent this because the
>>>>     protocol
>>>>     specification could do a good job of specifying all the basic
>>>>     types.
>>>>     If this really needs to be extended it would be probably done
>>>>     with a
>>>>     revised protocol specification.
>>>>
>>>>     Comments? Opinions?
>>>>
>>>>     Cheers,
>>>>
>>>>     Sebastian
>>>>
>>>
>>>
>>>
>>
>>
>


--------------050102070800090803000009
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Jeff,
<blockquote type="cite"
 cite="mid1D3D2C371FCBD947A7897FABBD3533A502960067@xsun01.ptp.hp.com">
  <div><span class="453254416-11062003"></span>&nbsp;</div>
  <div><span class="453254416-11062003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; So it sounds like "scope" is more or less
a way to pack multiple discrete records into a single template.&nbsp; </font></span></div>
</blockquote>
I would say: to group multiple data types that belong to the same
scope; the scope could be<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x0001 System&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x0002 Interface&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x0003 Line Card&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x0004 Cache&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x0005 Template <br>
For example (example section in the draft):<br>
&nbsp;&nbsp; - total number of Export Packets and total number of exported Flows
exported by each line card<br>
&nbsp;&nbsp; So scope = line card, data types = Export Packets and Exported Flows<br>
<br>
There was a previous discussion about exporting the number of flow
records per template. This is also possible<br>
So scope: = template, data type = Exported Flows
<blockquote type="cite"
 cite="mid1D3D2C371FCBD947A7897FABBD3533A502960067@xsun01.ptp.hp.com">
  <div><span class="453254416-11062003"><font face="Arial"
 color="#0000ff" size="2">This means that templates are no longer
necessarily in first normal form as some attributes may repeat.</font></span></div>
</blockquote>
Can you please elaborate.<br>
<blockquote type="cite"
 cite="mid1D3D2C371FCBD947A7897FABBD3533A502960067@xsun01.ptp.hp.com">
  <div><span class="453254416-11062003"></span>&nbsp;</div>
  <div><span class="453254416-11062003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; In general, I still think this is a lot of
complexity to address a use case which could be addressed with other
mechanisms already present in NFv9, i.e. treat all attributes as
equals from the protocol perspective, only have one template model,
distinguish between "option records" and "flow records".</font></span></div>
</blockquote>
Let me take 3 examples <br>
<br>
1. I export flow data records composed of src IP address, dst IP
address, Fragmented, number of packets, number of bytes<br>
where Fragmented is just 0 or 1.<br>
But the collecting process doesn't know about this Fragmented data
type; it has got 2 choices.<br>
- either it discards all the information because it doesn't understand
one of the data types<br>
- either it just sum up the number of packets and bytes per IP
addresses, regardless of the Fragmented, to at least report something
meaningfull. So a default action (summing up) is possible.<br>
<br>
2. I export an options data record composed of scope =&nbsp; line card X and
data type = the   sampling rate Y.<br>
But the collecting process doesn't know about the the   line card
scope; it can't even take a default action because it doesn't know
where to apply it to. The exporter doesn't know what to do with the
sampling rate, even if it understands the sampling rate data type.<br>
<br>
3. To follow up on the example 2, I export <u>flow </u>data records
composed of&nbsp; number of packets, number of bytes, input interface, line
card, sampling rate, exported flows, template ID. So data types are
equals.<br>
Let's assume that the collecting process knows about all data types.<br>
What should the sampling rate be applied to? Interface, line card, or
template?<br>
What should the export packet be applied to? Interface, line card, or
template?<br>
<br>
<blockquote type="cite"
 cite="mid1D3D2C371FCBD947A7897FABBD3533A502960067@xsun01.ptp.hp.com">
  <div><span class="453254416-11062003"></span>&nbsp;</div>
  <div><span class="453254416-11062003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; Since I believe that the information
transfer you describe can be accomplished with fewer moving parts in
the protocol, and since the "simplicity" of netflow was cited as a key
reason for its selection, can we make this simplification?</font></span></div>
</blockquote>
Can we make this simplification? Well, as explained during the last
IETF meeting, this new IPFIX protocol belongs to the IETF. So it will
become what the WG consensus will decide it to be!<br>
&nbsp;<br>
Nevertheless, I'm in favor of keeping the scope because of :<br>
0. in flow data records, we don't always what is the scope<br>
1. the scope is used as grouping factor (Sebastian's term)<br>
2. with flow data record (without scope) we can take a default action<br>
3. the scope is a more important data type to know about<br>
<br>
<br>
Regards, Benoit.<br>
<br>
<blockquote type="cite"
 cite="mid1D3D2C371FCBD947A7897FABBD3533A502960067@xsun01.ptp.hp.com">
  <div><span class="453254416-11062003"></span>&nbsp;</div>
  <div><span class="453254416-11062003"><font face="Arial"
 color="#0000ff" size="2">Regards,</font></span></div>
  <div><span class="453254416-11062003"></span>&nbsp;</div>
  <div><span class="453254416-11062003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; Jeff Meyer</font></span></div>
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px;">
    <div class="OutlookMessageHeader" dir="ltr" align="left"><font
 face="Tahoma" size="2">-----Original Message-----<br>
    <b>From:</b> Benoit Claise   [<a class="moz-txt-link-freetext" href="mailto:bclaise@cisco.com">mailto:bclaise@cisco.com</a>]<br>
    <b>Sent:</b> Wednesday, June 11, 2003 4:35   AM<br>
    <b>To:</b> Sebastian Zander<br>
    <b>Cc:</b> MEYER,JEFFREY D   (HP-Cupertino,ex1);
<a class="moz-txt-link-abbreviated" href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a><br>
    <b>Subject:</b> Re: [ipfix]   extensibility of the ipfix protocol<br>
    <br>
    </font></div>
Hi Jeff and   Sebastian,<br>
    <blockquote cite="mid3ECC2CC1.8090900@fokus.fraunhofer.de"
 type="cite">Jeff,<br>
      <br>
comments below <br>
      <br>
MEYER,JEFFREY D     (HP-Cupertino,ex1) wrote: <br>
      <blockquote type="cite">Sebastian, <br>
        <br>
&nbsp; I'd agree that making       the extensibility model more explicit is
desireable. <br>
&nbsp; &nbsp; I'm       still unclear on when or why one would extend
information into the <br>
header <br>
vs. extending the data template sent itself.&nbsp; I view       the Option
template as <br>
flagging "pseudo-flow records" which have a set       of attributes
which carry <br>
information other than actual flow details,       e.g. configuration
info or <br>
counters. <br>
        <br>
&nbsp; But isn't the       combination of having Extensible Flow Records
(for "real" <br>
data) and       Extensible Option Records (for "other" data)
sufficient to move <br>
any       form of data the exporter wants to export? <br>
        <br>
&nbsp; I guess this is       what Mark was saying.&nbsp; So I'd agree to that. <br>
      </blockquote>
      <br>
I     also agree <br>
      <br>
      <blockquote type="cite">&nbsp; I would see the same "Information
Model"       and extension model being used <br>
for both Flow Record and Options. <br>
        <br>
        <br>
&nbsp; So to clarify, the header is fixed.&nbsp; There is a       distinction
between flow <br>
records and "other" data transmitted by the       exporter.&nbsp; And a
common way <br>
of defining how attributes which       appear in either flow or option
records <br>
will be used. <br>
        <br>
&nbsp;       I'm not sure on why the "Scope" options should be treated
differently <br>
than any other attribute which may appear in an Option Record (Section
 6.1) <br>
in NFv9 specification.&nbsp; Seems like things would be simpler       and
just as <br>
effective if there were just a "Scope" attribute which       could
appear in <br>
Option records.&nbsp; In this case an Options template       would be
identical <br>
to a Flow Template except it would have a FlowSet       id of 1 vs. 0. <br>
        <br>
&nbsp; Does that work? </blockquote>
    </blockquote>
Jeff,<br>
Yes it would work.<br>
One argument for   treating the scope differently is that the scope
must be applied to all   options data records.<br>
And the Scope is an important data type. If you don't   know about it,
you can't apply the "action" that is associated with the   options
flow record.<br>
For example: if the scope is the line card X and the   sampling rate Y
and if the collector doesn't know abouth the scope for the   line
card, the exporter doesn't know that the number of bytes should be  
multipled by the sampling rate.<br>
Ok, that would be almost the same for an   unknow data types in the
flow data record, but that one could just be   reported, without
taking an "action"<br>
    <br>
    <blockquote cite="mid3ECC2CC1.8090900@fokus.fraunhofer.de"
 type="cite">
      <blockquote type="cite"><br>
      </blockquote>
      <br>
I must admit that i don't 100%     understand how scope is supposed to
work. <br>
The example in 10.4 and 10.5     seems somewhat flawed. The draft says
there are <br>
N scope fields and N     option fields. Must the number of scope
fields be equal <br>
to the number of     option fields? If yes this seems to waste lots of
space if the <br>
scope     does not change (and it is not the case in the example). If
not (probably <br>
the authors meant M and N) the question is how to map the scope fields
 to the <br>
options fields when there is more than 1 scope field (seems    
impossibe)? </blockquote>
Sebastian, you are right that the intention is to   have M and N. This
has been corrected in the latest draft.<br>
How to map the   scope fields to the options fields when there is more
than 1 scope   field?<br>
The scope can be limited further by listing multiple scopes which  
all have to match at the same time.<span lang="EN-US"
 style="font-size: 12pt; font-family: 'Courier New';"></span><br>
    <blockquote cite="mid3ECC2CC1.8090900@fokus.fraunhofer.de"
 type="cite"><br>
      <br>
Making scope another attribute sounds somewhat good.     However has
scope some <br>
kind of grouping functionality </blockquote>
Yes   exactly. See the previous answer to Jeff<br>
    <blockquote cite="mid3ECC2CC1.8090900@fokus.fraunhofer.de"
 type="cite">or     must it explicitly appear before each option? <br>
Can scopes be combined     such as e.g. this option is per interface
vs. this option <br>
is per     template per interface?</blockquote>
Exactly.<br>
    <br>
Regards, Benoit.<br>
    <blockquote cite="mid3ECC2CC1.8090900@fokus.fraunhofer.de"
 type="cite">I     think my questions are about grouping because <br>
scope seems to have some     kind of grouping function... <br>
      <br>
Cheers, <br>
      <br>
Sebastian <br>
      <br>
      <blockquote type="cite"><br>
Regards, <br>
        <br>
&nbsp; Jeff Meyer <br>
        <br>
-----Original Message----- <br>
From: Sebastian Zander [<a class="moz-txt-link-freetext"
 href="mailto:zander@fokus.fraunhofer.de">mailto:zander@fokus.fraunhofer.de</a>]<br>
Sent: Wednesday, May 21, 2003 5:19 PM <br>
To: MEYER,JEFFREY D       (HP-Cupertino,ex1) <br>
Cc: <a class="moz-txt-link-abbreviated"
 href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a> <br>
Subject: Re: [ipfix] extensibility of the ipfix protocol <br>
        <br>
        <br>
Jeff, <br>
        <br>
MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: <br>
        <br>
        <blockquote type="cite">Sebastian, <br>
          <br>
&nbsp;One of the issues of         talking about extensibility in the
generic sense is <br>
that it creates         the temptation to specify generality without
any driving <br>
use         case.&nbsp; "Someone may want to ..." seems like a slippery
slope in <br>
        </blockquote>
        <br>
bounding <br>
        <br>
        <blockquote type="cite">requirements. <br>
          <br>
&nbsp;In particular the         case (1) extending fields in the header
sounds <br>
        </blockquote>
        <br>
dubious. <br>
        <br>
        <blockquote type="cite">&nbsp;Since IPFIX is about getting flow
records         from the exporter to the <br>
collector, <br>
what is the purpose of         allowing arbitrary header extensions? <br>
        </blockquote>
        <br>
        <br>
The purpose       is to send information per packet which is
associated to or <br>
necessary       for using the rest of the information contained in the
packet. For <br>
me       its pretty obvious that you need such an extension mechanism.
And as Mark <br>
pointed out this is already supported by the use of option templates. <br>
        <br>
netflow certainly meets the extensibility reqs but the netflow      
drafts do <br>
*not* <br>
a good job IMO in explaining its extensibility       compared to e.g.
what <br>
Diameter <br>
does. Instead of letting the reader       guess the ipfix draft should
have more <br>
verbage. <br>
        <br>
        <br>
        <blockquote type="cite">&nbsp; In case (2), I'd certainly recommend
 option (b), making an explicit <br>
separation of namespaces (in this         case integer values) by
using unique <br>
vendor ids as independent         "namespace authorities" seems like
common sense. <br>
SNMP's been doing         this for years, and Diameter is also
following this <br>
convention as         you point out. <br>
          <br>
&nbsp;As for case (3), my understanding is that         explicit type
information in <br>
the payload/template itself did not         achieve consensus.&nbsp;&nbsp; This
does mean <br>
that the numeric id         (and optional vendorId) needs some concept
of type, <br>
in a supporting         document.&nbsp; Having each attribute specify its
type by <br>
reference         to a type space defined in the base IPFIX
Information Model <br>
is the         way to go here (in my opinion). <br>
        </blockquote>
        <br>
        <br>
Yeah, but the       protocol draft must be aligned somehow to the
information <br>
model draft       e.g. where are the types defined, where is the
encoding <br>
defined... <br>
        <br>
Cheers, <br>
        <br>
Sebastian <br>
        <br>
        <br>
        <blockquote type="cite">&nbsp;When a vendor extends the set of     
attributes, chosing a well defined <br>
type would be preferred to         inventing a new type.&nbsp; If the
vendor cannot <br>
resist the         overwhelming temptation to create new types, it can
be defined in their         own information model. <br>
          <br>
          <br>
Regards, <br>
          <br>
&nbsp;Jeff Meyer <br>
          <br>
-----Original Message----- <br>
From: Sebastian Zander [<a class="moz-txt-link-freetext"
 href="mailto:zander@fokus.fraunhofer.de">mailto:zander@fokus.fraunhofer.de</a>]<br>
Sent: Tuesday, May 06, 2003 6:55 PM <br>
To: <a class="moz-txt-link-abbreviated"
 href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a> <br>
Subject: [ipfix] extensibility of the ipfix protocol <br>
          <br>
          <br>
Hi, <br>
          <br>
although extensibility is mandatory by the requirements there        
hasn't <br>
been a lot discussion on how to do it and the chosen         candidate
protocol <br>
doesn't say much about extensibility. So here are         my thoughts
about <br>
extensibility. <br>
          <br>
The protocol specification         must define how the protocol can be
extended. <br>
          <br>
I see the         following (but there may be more) ways of extending
the <br>
protocol: <br>
          <br>
1. Extending the fixed packet header <br>
This would allow to add         new header fields without changing the <br>
protocol specification. <br>
          <br>
A bit (X) could be stolen from version to indicate the presence       
of <br>
extension header(s). Extension header(s) follow the fixed header      
if <br>
X=1. Extension header(s) consists of type, length and value. <br>
          <br>
2. Extending the attribute/field space <br>
This is certainly         needed. It could be done at least in two
ways: <br>
a) A flat number         space where numbers are specified in
extension <br>
&nbsp;&nbsp; RFCs and         registered by IANA. A nice thing would a dynamic <br>
&nbsp;&nbsp; space         where numbers are not defined by IANA but could be
negotiated <br>
&nbsp;&nbsp; out of band (see payload type in the RTP         specification).
Such a <br>
&nbsp;&nbsp; space could also be used as safe         playground. <br>
b) A number space which is defined in extension RFCs         (IANA)
and the <br>
&nbsp;&nbsp; possibility of using vendor specific         attributes by having
an optional <br>
&nbsp;&nbsp; vendor ID field in the         template specification. The vendor
ID would <br>
&nbsp;&nbsp; be IANA         assigned but the vendor then could use its private
field ID <br>
&nbsp;&nbsp; space (see the Diameter Base protocol specification).         Adds
more <br>
&nbsp;&nbsp; complexity and overhead to the protocol but         could be very
useful <br>
&nbsp;&nbsp; when the protocol becomes widely         adopted and a lot of
extensions <br>
&nbsp;&nbsp; are done. <br>
          <br>
3.         Extending the type space (if there are types at all) <br>
Probably there         won't be much need to extent this because the
protocol <br>
specification         could do a good job of specifying all the basic
types. <br>
If this         really needs to be extended it would be probably done
with a <br>
revised         protocol specification. <br>
          <br>
Comments? Opinions? <br>
          <br>
Cheers, <br>
          <br>
Sebastian <br>
          <br>
        </blockquote>
        <br>
        <br>
        <br>
      </blockquote>
      <br>
      <br>
    </blockquote>
    <br>
  </blockquote>
</blockquote>
<br>
</body>
</html>

--------------050102070800090803000009--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 12 06:22:09 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02316
	for <ipfix-archive@lists.ietf.org>; Thu, 12 Jun 2003 06:22:09 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QOtF-0007nf-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 12 Jun 2003 05:01:05 -0500
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 19QOtE-0007nZ-00
	for ipfix@net.doit.wisc.edu; Thu, 12 Jun 2003 05:01:04 -0500
Received: from cisco.com (ams-clip-vpn-dhcp4289.cisco.com [10.61.80.192])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h5CA0jp02027;
	Thu, 12 Jun 2003 12:00:45 +0200 (CEST)
Message-ID: <3EE84F4C.6020804@cisco.com>
Date: Thu, 12 Jun 2003 12:00:44 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: ipfix@net.doit.wisc.edu, Benoit Claise <bclaise@cisco.com>
Subject: Re: [ipfix] draft-claise-netflow-version9-02.txt
References: <1D3D2C371FCBD947A7897FABBD3533A502960068@xsun01.ptp.hp.com>
In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A502960068@xsun01.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Hi Jeff,

>  Are the set of information items defined in -02 the complete set as 
>you see it or do you think there are additional information items?
>  I know Paul Calato is independently tracking the set down, but wanted
>to understand your perspective.
>
There are some additional ones that we have assigned already.
The intend is that the draft-claise-netflow-version9-02.txt will be used 
to create an Information RFC.
So we were thinking to describe in the draft only what NetFlow version 9 
does today.
So the additional data types could potentially be implemented in the future.
Let me know how the WG would like to proceed.

>
>  For the field identifier range (Section 8), I imagine resuing the id's 
>already defined as part of NFv9 would make sense. 
>
That's good news. Reusing what has been done is always a good thing.
Note: we will anyway have to change a little bit the format for the IANA 
versus private data types.

> If new information
>items are identified, is the number 79 the starting point?
>
Yes. (80 just to be fully correct)

>
>  Also has the IANA disposition of these identifiers been discussed.  E.g.
>will control of these be passed over to IANA as part of the process
>of this WG's output?
>
Yes, this is my understanding.

Regards, Benoit.

>
>
>Regards,
>
>  Jeff Meyer
>
>  
>
>>-----Original Message-----
>>From: Benoit Claise [mailto:bclaise@cisco.com]
>>Sent: Wednesday, June 11, 2003 4:30 AM
>>To: ipfix@net.doit.wisc.edu
>>Subject: [ipfix] draft-claise-netflow-version9-02.txt
>>
>>
>>Dear all, 
>>
>>The draft-claise-netflow-version9-02.txt has been produced 
>>and is on its way to be posted by the IETF.
>>As some excerpts could be reused in the protocol and 
>>information IPFIX drafts, and knowing the deadlines that 
>>IPFIX faces, you can find a copy in the mean time by 
>>following the procedure below.
>>
>>
>>Regards, Benoit.
>>
>>
>>The file names is:
>>* draft-claise-netflow-version9-02.txt (NetFlow version 9 
>>latest draft)
>>
>>To get these files, please do the following...
>>
>>   1. With a Netscape or Internet Explorer web browser open
>>      the following URL:
>>        http://www.cisco.com/pcgi-bin/specialaccess.cgi
>>   2. At the 'Special Access Code' prompt, enter in TLGMQSEV
>>   3. Click on the 'Execute' button.  This will bring you
>>      to a web page listing your files for pickup.
>>   4. Select each file listed.  Each selection will take
>>      you to the Software Download web page; click on any
>>      Site listed to download your file to your local disk.
>> 
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
>>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 Jun 12 09:05:51 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09092
	for <ipfix-archive@lists.ietf.org>; Thu, 12 Jun 2003 09:05:51 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QRUn-0004eZ-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 12 Jun 2003 07:48:01 -0500
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 19QRUl-0004eU-00
	for ipfix@net.doit.wisc.edu; Thu, 12 Jun 2003 07:47:59 -0500
Received: from cisco.com (ams-clip-vpn-dhcp4289.cisco.com [10.61.80.192])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h5CClBp00107;
	Thu, 12 Jun 2003 14:47:12 +0200 (CEST)
Message-ID: <3EE8764F.4070605@cisco.com>
Date: Thu, 12 Jun 2003 14:47:11 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tal Givoly <givoly@xacct.com>
CC: "MEYER,JEFFREY D \(HP-Cupertino,ex1\)" <jeff.meyer2@hp.com>,
        Mark Fullmer <maf@eng.oar.net>, calato@riverstonenet.com,
        ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] drawing the line between protocol and data model document
References: <DLEIIIOHMNPJPNMKGEFDEEGIDKAA.givoly@xacct.com>
In-Reply-To: <DLEIIIOHMNPJPNMKGEFDEEGIDKAA.givoly@xacct.com>
Content-Type: multipart/alternative;
 boundary="------------070001080608070708060108"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.
--------------070001080608070708060108
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Tal, Jeff,

[let me reply to both of you in a single email]

> Benoit,
>  
> I agree with Jeff. I would add that, no more than 2 options should be 
> available for bytes/packet counters (32/64-bit unsigned integers).
>  
> But I would consider offering *only* a 64-bit value for byte counters. 
> From SNMP we learned that 32-bit byte counters cause countless 
> problems. Since IPFIX byte counters may be a result of aggregates, 
> with today's networks it is very feasible to overflow the 32-bit 
> integer container.

How often do you poll the SNMP variables like interface counters? 5 minutes?
This is order of magnitude higher than the flow expiration, in most of 
the cases.

http://www.ietf.org/internet-drafts/draft-claise-netflow-9-02.txt
    -> 3.2 Flow Expiration

   A Flow is considered to be inactive if no packets belonging to the 
   Flow have been observed at the Observation Point for a given timeout 
   interval otherwise it is considered as an active flow.  
   A Flow can be exported under the following conditions: 
    
      1. If the Exporter can detect the end of a Flow, it SHOULD export 
      the Flow Records at the end of the Flow. For example, a Flow 
      generated by TCP [3] 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, with a minimum 
      value of 0 for an immediate expiration. For example, a Flow 
      generated by UDP [2] type of traffic. 
       
      3. For long-lasting Flows, the Exporter SHOULD export the Flow 
      Records on a regular basis. This periodicity SHOULD be 
      configurable. 
       
      4. If the Exporter experiences internal constraints, a Flow MAY 
      be forced to expire prematurely (for example, counters wrapping 
      or low memory). 

So it's only in case 3 (so potentially an aggregation, as you described) that we could potentially needs a higher counter.
And in that case again, a simple solution is to export the flow records just before it reaches the max value of counter32 (in case the length for counter32 is choosen).

But if you don't want that, there is also another solution: when this case 3. occurs, you can define a new template with the length corresponding to counter64.
And then you have 2 templates: one with counter32 (used most of the time) and one with counter64 (used in a few cases).

Another solution, nothing prevents you to export flow data records always with counter64

See below...

>  
> Tal
>
>     -----Original Message-----
>     *From:* majordomo listserver
>     [mailto:majordomo@mil.doit.wisc.edu]*On Behalf Of *MEYER,JEFFREY D
>     (HP-Cupertino,ex1)
>     *Sent:* Wednesday, June 11, 2003 10:00 AM
>     *To:* 'Benoit Claise'
>     *Cc:* Mark Fullmer; calato@riverstonenet.com; ipfix@net.doit.wisc.edu
>     *Subject:* RE: [ipfix] drawing the line between protocol and data
>     model document
>
>     Hi,
>      
>       >From a practical perspective, simply saying that a field is
>     numeric and may be encoded as 1 or 100 bytes seems like it puts an
>     unnecessary and unjustified burden on the collector, or any other
>     app which might want to handle this data.
>
Am I correct that the burden would only be when you decode the template 
records?
Because when you receive a Data FlowSet, the collecting process must 
read the FlowSet ID and automatically know the data type length.

>      
>       Is there some particular reason why saying a specific
>     information item, e.g. numBytes, is a 32-bit integer or a 64-bit
>     integer is considered undesireable.
>
But then, why to limit to 32-bit and 64-bit integer? What about other 
possibilities? Where to stop? Then we end up with a long information 
model because this principle of 32-bit, 64-bit integer should be then 
applied to all data type that are counters.

>     It certainly seems like the developer of a consuming application
>     would benefit from knowing how to target variables in their
>     application for given information items.  I guess one could assume
>     that everything will fit in a 64-bit integer and code your app
>     that way, but again, this seems like an unnecessary burden for
>     unclear gains.
>
The gain, as I see it, is in the flexibility with a simple information model

Regards, Benoit.

>      
>       I don't think anything needs to change in the protocol.  Simply
>     a more constrained approach to dealing with numeric fields with
>     explicit types.
>      
>     Regards,
>
>       Jeff Meyer
>
>         -----Original Message-----
>         *From:* Benoit Claise [mailto:bclaise@cisco.com]
>         *Sent:* Wednesday, June 11, 2003 4:31 AM
>         *To:* Benoit Claise
>         *Cc:* Mark Fullmer; calato@riverstonenet.com;
>         ipfix@net.doit.wisc.edu
>         *Subject:* Re: [ipfix] drawing the line between protocol and
>         data model document
>
>         Dear all,
>
>>         Mark,
>>
>>>On Thu, May 01, 2003 at 10:51:49AM -0400, calato@riverstonenet.com wrote:
>>>
>>><snip>
>>>
>>>  
>>>
>>>>The richness of the protocol encoding specification is another
>>>>matter. The protocol would reference each element in the data
>>>>model and define exaclty how that element is encoded. In the above 
>>>>example, the protocol is free to encode that as an unsigned byte 
>>>>if the value is < 256. 
>>>>    
>>>>
>>>
>>>The ramifications of doing this with a template based system are a bit
>>>ugly.  Consider a flow with just 2 counters -- octets, packets.
>>>Each could have a 1 to 8 byte encoding.  That's a potential of 64
>>>different templates for representing 1 type of flow.
>>>
>>>This (at first glance) looks like it adds considerable cycles to the
>>>encode / decode process to save a few bytes in the transport.
>>>
>>>The current v9 spec appears to allow this, but only for IN_BYTES and
>>>IN_PKTS.
>>>
>>>  
>>>
>>>>                                          counter with length
>>>>   IN_BYTES                 1       N     N x 8 bits for bytes
>>>>                                          associated with an IP Flow
>>>>    
>>>>
>>>
>>>Is this true?  Benoit?
>>>  
>>>
>>         I'm trying to catch up with my IPIFX emails; I know I'm late
>>         on this thread, which seems to have reached consensus as far
>>         as I can tell, but as this is a direct question to me, let me
>>         answer.
>>         Actually, there are:
>>         BYTES            1             4             field type for
>>         the 32 bit bytes counter
>>         BYTES_64      23           8             field type for the
>>         64 bit bytes counter
>
>         Let me reply to my own email because, after speaking to
>         different people, I have to correct what I said.
>         We actually do:
>
>                                          Incoming counter with length
>   IN_BYTES                 1       N     N x 8 bits for bytes
>                                          associated with an IP Flow
>
>                                          Incoming counter with length
>   IN_PKTS		    2       N     N x 8 bits for packets
>                                          associated with an IP Flow
>
>And no BYTES_64 is defined.
>
>Regards, Benoit.
>
>
>>
>>
>>         So the draft that you refer to needs a quick update.
>>         <!--[endif]-->
>>         Regards, Benoit
>>
>>
>>
>>>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/
>>>  
>>>
>>
>


--------------070001080608070708060108
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Tal, Jeff,<br>
<br>
[let me reply to both of you in a single email]<br>
<blockquote type="cite"
 cite="midDLEIIIOHMNPJPNMKGEFDEEGIDKAA.givoly@xacct.com">
  <title></title>
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2722.900" name="GENERATOR">
  <div><span class="768200504-12062003"><font face="Arial"
 color="#0000ff" size="2">Benoit,</font></span></div>
  <div><span class="768200504-12062003"></span>&nbsp;</div>
  <div><span class="768200504-12062003"><font face="Arial"><font
 color="#0000ff"><font size="2">I agree with Jeff. I would add that<span
 class="768200504-12062003">, no more than&nbsp;2 options should be
available for bytes/packet counters (32/64-bit unsigned integers).</span></font></font></font></span></div>
  <div>&nbsp;</div>
  <div><font face="Arial" color="#0000ff" size="2">But I would consider
offering&nbsp;<span class="768200504-12062003"><strong>only</strong> </span>a
64-bit value for byte counters. From SNMP we learned that 32-bit byte
counters cause countless problems. Since IPFIX byte counters may be a
result of aggregates, with today's networks it is very feasible to
overflow the 32-bit integer container.</font></div>
</blockquote>
How often do you poll the SNMP variables like interface counters? 5
minutes?<br>
This is order of magnitude higher than the flow expiration, in most of
the cases.<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-claise-netflow-9-02.txt">http://www.ietf.org/internet-drafts/draft-claise-netflow-9-02.txt</a><br>
&nbsp;&nbsp;&nbsp; -&gt; 3.2 Flow Expiration<br>
<pre>   A Flow is considered to be inactive if no packets belonging to the 
   Flow have been observed at the Observation Point for a given timeout 
   interval otherwise it is considered as an active flow.  
   A Flow can be exported under the following conditions: 
    
      1. If the Exporter can detect the end of a Flow, it SHOULD export 
      the Flow Records at the end of the Flow. For example, a Flow 
      generated by TCP [3] 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, with a minimum 
      value of 0 for an immediate expiration. For example, a Flow 
      generated by UDP [2] type of traffic. 
       
      3. For long-lasting Flows, the Exporter SHOULD export the Flow 
      Records on a regular basis. This periodicity SHOULD be 
      configurable. 
       
      4. If the Exporter experiences internal constraints, a Flow MAY 
      be forced to expire prematurely (for example, counters wrapping 
      or low memory). 

So it's only in case 3 (so potentially an aggregation, as you described) that we could potentially needs a higher counter.
And in that case again, a simple solution is to export the flow records just before it reaches the max value of counter32 (in case the length for counter32 is choosen).

But if you don't want that, there is also another solution: when this case 3. occurs, you can define a new template with the length corresponding to counter64.
And then you have 2 templates: one with counter32 (used most of the time) and one with counter64 (used in a few cases).

Another solution, nothing prevents you to export flow data records always with counter64

See below...
</pre>
<blockquote type="cite"
 cite="midDLEIIIOHMNPJPNMKGEFDEEGIDKAA.givoly@xacct.com">
  <div><span class="768200504-12062003"></span>&nbsp;</div>
  <div><span class="768200504-12062003"><font face="Arial"
 color="#0000ff" size="2">Tal</font></span></div>
  <blockquote dir="ltr" style="margin-right: 0px;">
    <div class="OutlookMessageHeader" dir="ltr" align="left"><font
 face="Tahoma" size="2">-----Original Message-----<br>
    <b>From:</b> majordomo listserver  
[<a class="moz-txt-link-freetext" href="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</a>]<b>On Behalf Of </b>MEYER,JEFFREY
D   (HP-Cupertino,ex1)<br>
    <b>Sent:</b> Wednesday, June 11, 2003 10:00   AM<br>
    <b>To:</b> 'Benoit Claise'<br>
    <b>Cc:</b> Mark Fullmer;   <a class="moz-txt-link-abbreviated" href="mailto:calato@riverstonenet.com">calato@riverstonenet.com</a>;
<a class="moz-txt-link-abbreviated" href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a><br>
    <b>Subject:</b> RE:   [ipfix] drawing the line between protocol and
data model   document<br>
    <br>
    </font></div>
    <div><span class="718225916-11062003"><font face="Arial"
 color="#0000ff" size="2">Hi,</font></span></div>
    <div><span class="718225916-11062003"></span>&nbsp;</div>
    <div><span class="718225916-11062003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; &gt;From a practical perspective, simply
saying that a field is   numeric and may be encoded as 1 or 100 bytes
seems like it puts an unnecessary   and unjustified burden on the
collector, or any other app which might want to   handle this data.</font></span></div>
  </blockquote>
</blockquote>
Am I correct that the burden would only be when you decode the template
records?<br>
Because when you receive a Data FlowSet, the collecting process must
read the FlowSet ID and automatically know the data type length.<br>
<blockquote type="cite"
 cite="midDLEIIIOHMNPJPNMKGEFDEEGIDKAA.givoly@xacct.com">
  <blockquote dir="ltr" style="margin-right: 0px;">
    <div><span class="718225916-11062003"></span>&nbsp;</div>
    <div><span class="718225916-11062003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; Is there some particular reason why saying
a specific   information item, e.g. numBytes, is a 32-bit integer or a
64-bit integer is   considered undesireable. <br>
    </font></span></div>
  </blockquote>
</blockquote>
But then, why to limit to 32-bit and 64-bit integer? What about other
possibilities? Where to stop? Then we end up with a long information
model because this principle of 32-bit, 64-bit integer should be then
applied to all data type that are counters.<br>
<blockquote type="cite"
 cite="midDLEIIIOHMNPJPNMKGEFDEEGIDKAA.givoly@xacct.com">
  <blockquote dir="ltr" style="margin-right: 0px;">
    <div><span class="718225916-11062003"><font face="Arial"
 color="#0000ff" size="2"> It certainly seems like the developer of a  
consuming application would benefit from knowing how to target
variables in   their application for given information items.&nbsp; I guess
one could assume   that everything will fit in a 64-bit integer and
code your app that way, but   again, this seems like an unnecessary
burden for unclear   gains.</font></span></div>
  </blockquote>
</blockquote>
The gain, as I see it, is in the flexibility with a simple information
model<br>
<br>
Regards, Benoit.<br>
<br>
<blockquote type="cite"
 cite="midDLEIIIOHMNPJPNMKGEFDEEGIDKAA.givoly@xacct.com">
  <blockquote dir="ltr" style="margin-right: 0px;">
    <div><span class="718225916-11062003"></span>&nbsp;</div>
    <div><span class="718225916-11062003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; I don't think anything needs to change in
the protocol.&nbsp;   Simply a more constrained approach to dealing with
numeric fields with   explicit types.</font></span></div>
    <div><span class="718225916-11062003"></span>&nbsp;</div>
    <div><span class="718225916-11062003"><font face="Arial"
 color="#0000ff" size="2">Regards,</font></span></div>
    <div><span class="718225916-11062003"><font face="Arial"
 color="#0000ff" size="2"><br>
&nbsp; Jeff Meyer</font></span></div>
    <blockquote
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px;">
      <div class="OutlookMessageHeader" dir="ltr" align="left"><font
 face="Tahoma" size="2">-----Original Message-----<br>
      <b>From:</b> Benoit Claise     [<a class="moz-txt-link-freetext" href="mailto:bclaise@cisco.com">mailto:bclaise@cisco.com</a>]<br>
      <b>Sent:</b> Wednesday, June 11, 2003 4:31     AM<br>
      <b>To:</b> Benoit Claise<br>
      <b>Cc:</b> Mark Fullmer;     <a class="moz-txt-link-abbreviated" href="mailto:calato@riverstonenet.com">calato@riverstonenet.com</a>;
<a class="moz-txt-link-abbreviated" href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a><br>
      <b>Subject:</b> Re:     [ipfix] drawing the line between protocol
and data model     document<br>
      <br>
      </font></div>
Dear all,<br>
      <blockquote cite="mid3EDCB48D.40207@cisco.com" type="cite">Mark,
 <blockquote cite="mid20030501162116.B33173@net.ohio-state.edu"
 type="cite">
          <pre wrap="">On Thu, May 01, 2003 at 10:51:49AM -0400, <a
 class="moz-txt-link-abbreviated" href="mailto:calato@riverstonenet.com">calato@riverstonenet.com</a> wrote:

&lt;snip&gt;

  </pre>
          <blockquote type="cite">
            <pre wrap="">The richness of the protocol encoding specification is another
matter. The protocol would reference each element in the data
model and define exaclty how that element is encoded. In the above 
example, the protocol is free to encode that as an unsigned byte 
if the value is &lt; 256. 
    </pre>
          </blockquote>
          <pre wrap=""><!---->
The ramifications of doing this with a template based system are a bit
ugly.  Consider a flow with just 2 counters -- octets, packets.
Each could have a 1 to 8 byte encoding.  That's a potential of 64
different templates for representing 1 type of flow.

This (at first glance) looks like it adds considerable cycles to the
encode / decode process to save a few bytes in the transport.

The current v9 spec appears to allow this, but only for IN_BYTES and
IN_PKTS.

  </pre>
          <blockquote type="cite">
            <pre wrap="">                                          counter with length
   IN_BYTES                 1       N     N x 8 bits for bytes
                                          associated with an IP Flow
    </pre>
          </blockquote>
          <pre wrap=""><!---->
Is this true?  Benoit?
  </pre>
        </blockquote>
I'm trying to catch up with my IPIFX emails; I know       I'm late on
this thread, which seems to have reached consensus as far as I      
can tell, but as this is a direct question to me, let me       answer.<br>
Actually, there are:<br>
BYTES&nbsp; &nbsp;&nbsp; &nbsp;&nbsp;       &nbsp; &nbsp; 1 &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; 4       &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; field type
for the 32       bit bytes counter<br>
BYTES_64&nbsp;&nbsp; &nbsp;&nbsp; 23&nbsp;&nbsp;       &nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;       8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;       field
type for the 64 bit bytes counter</blockquote>
Let me reply to my own     email because, after speaking to different
people, I have to correct what I     said.<br>
We actually do:<br>
      <pre wrap="">                                          Incoming counter with length
   IN_BYTES                 1       N     N x 8 bits for bytes
                                          associated with an IP Flow

                                          Incoming counter with length
   IN_PKTS		    2       N     N x 8 bits for packets
                                          associated with an IP Flow

And no BYTES_64 is defined.

Regards, Benoit.

<span lang="EN-US"
 style="font-size: 12pt; font-family: 'Times New Roman';"><span></span><span></span></span></pre>
      <blockquote cite="mid3EDCB48D.40207@cisco.com" type="cite"><br>
        <br>
So the       draft that you refer to needs a quick       update.<br>
&lt;!--[endif]--&gt;<O:IDMAP v:ext="edit" data="3"></O:IDMAP><br>
Regards, Benoit<br>
        <br>
        <br>
        <br>
        <blockquote cite="mid20030501162116.B33173@net.ohio-state.edu"
 type="cite">
          <pre wrap="">mark

--
Help        <a class="moz-txt-link-freetext"
 href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help<a
 class="moz-txt-link-rfc2396E"
 href="inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay">" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"</a>unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext"
 href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>
  </pre>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
  </blockquote>
</blockquote>
<br>
</body>
</html>

--------------070001080608070708060108--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 12 10:35:57 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13961
	for <ipfix-archive@lists.ietf.org>; Thu, 12 Jun 2003 10:35:56 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QSw7-00078N-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 12 Jun 2003 09:20:19 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19QSw6-00078F-00
	for ipfix@net.doit.wisc.edu; Thu, 12 Jun 2003 09:20:18 -0500
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5CEKBjc006174;
	Thu, 12 Jun 2003 07:20:11 -0700 (PDT)
Received: from cisco.com (sjc-vpn3-463.cisco.com [10.21.65.207]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id HAA20165; Thu, 12 Jun 2003 07:20:09 -0700 (PDT)
Message-ID: <3EE88C18.99B1383D@cisco.com>
Date: Thu, 12 Jun 2003 07:20:08 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tal Givoly <givoly@xacct.com>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] IPFIX-ARCH : Functional flow diagram.
References: <DLEIIIOHMNPJPNMKGEFDCEGIDKAA.givoly@xacct.com>
Content-Type: multipart/alternative;
 boundary="------------19987256AD20907DA2C004EC"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


--------------19987256AD20907DA2C004EC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tal,

   I agree with you that the diagram does not show the complete
interconnects.
   Sorry, I did not mention that this diagram is in addition to the
already existing
   diagram in the arch spec that shows the interconnects which needs
some
   modification.
   I was planning to just put the important functions in the diagram and
the detail
   text for each module would  in the different sections. But then maybe
we need
   to still modify the text in the blocks.
   What did you mean by aggregation? Is it of flows ? There is text in
"flow recording
   process" which mentions about aggregate statistics. But that has
nothing to do with
   aggregation itself.
   Anonymization IMO is a protocol function and we need to add this to
the rule and
   function.

Thanks
Ganesh


Tal Givoly wrote:

>  Ganesh,Usually, diagrams are useful for illustration of concepts, but
> aren't ideal for specification. If you would like this to be a
> specification of the inner workings of the metering process and
> exporting process, I would recommend you add the following:-
> Identification of all modules and interconnects- Text that describes
> each of these modules and interconnects to disambiguate it for the
> reader.Regarding the content itself - I believe aggregation is not
> clear. Also annonymization location isn't clear.It seems to me to make
> more sense to have two distinct diagrams - one at the high level
> showing MP (many to 1) -> EP. Then it would be possible to blow up the
> MP and the EP independently and discuss them independently. The EP
> depends primarily on the protocol features while the MP would have the
> support for most of the capabilities such as timestamping, and others
> that you discuss.Tal-----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On
> Behalf Of Ganesh Sadasivan
> Sent: Wednesday, June 11, 2003 11:58 AM
> To: ipfix@net.doit.wisc.edu
> Subject: [ipfix] IPFIX-ARCH : Functional flow diagram.
>
>
>      Hi,
>         I want to add this figure into the architecture spec.
>      Please go through this send
>         send any comments/corrections.
>
>                          Packet(s) coming into Observation
>      Point(s)
>                          |                                   |
>                          |                                   |
>                          v                                   v
>        +-----------------+-------------------------+
>      +-----+------+
>        |           Metering Process on an          |
>      |            |
>        |              Observation Point            |
>      |            |
>        |  packet header capturing                  |
>      |            |
>        |         |                                 |   |
>      Metering   |
>        |    timestamping                           |   |
>      Process    |
>        |         |                                 |   | on
>      an      |
>        |         v                                 |   |
>      Observation|
>        |  +------+                                 |   |
>      Point      |
>        |  |      |                                 |
>      |            |
>        |  |   sampling Si (1:1 in case of no       |
>      |            |
>        |  |      |          sampling)              |
>      |            |
>        |  | classifying Fi (NULL when No criteria) |
>      |            |
>        |  |      |                                 |
>      |            |
>        |  +------+                                 |
>      |            |
>        |         |                                 |
>      |            |
>        +---------+---------------------------------+
>      +-----+------+
>                  |                                           |
>                Flows (identified by observation domain)    Flows
>                  +----...
>      +--------+...
>                  |                                           v
>                  |
>      +-------------------------------------+----------------+
>                  |     |             Flow Recording
>      Process(*)                |
>                  |     | +----------------------+
>      +------------------+    |
>                  |     | | Flow data base       |<----|Provide
>      non-flow  |    |
>                  |     | | (includes flows      |     |
>      information (Eg. |    |
>                  |     | | from all obs.        |     | router
>      state)    |    |
>                  |     | | points in an obs.    |
>      +------------------+    |.....
>                  |     | | domain)
>      |                             |
>                  |     | |                      |
>      +------------------+    |
>                  |     | |                      |<----|Maintain
>      aggregate|    |
>                  |     | |                      |     |
>      statistics       |    |
>                  |     | +----------------------+
>      +------------------+    |
>                  |
>      +-------------------------------+----------------------+
>                  |                                     |
>                  |        Flow Database (identified by
>      observation domain)
>                  |
>      +------------------------....
>                  v                                     v
>
>      -----------+-------------------------------------+--------------------------+
>
>      |           |            Export Process
>      |                          |
>      |           |
>      +----------------------... |
>      |
>      +---------+------------------------------------------------------------+
>      |
>      | |         v                  IPFIX
>      Protocol                            |   |
>      | |+---------------------------------+
>      +-------------------------------+|   |
>      | || Rules for                       |
>      |Functions                      ||   |
>      | || - Picking & sending templates   |  |- Packetize
>      selected control   ||   |
>      | || - Picking & sending data records|->|  & data
>      information into      ||   |
>      | || - Timing out flows              |  |  IPFIX export
>      packet.         ||...|
>      | || - Encoding template & data      |  |- Handle export
>      errors         ||   |
>      | || - Selecting flows for export(*) |  |- Handle timeouts &
>      overloads  ||   |
>      | |+---------------------------------+
>      +-------------------------------+|   |
>      |
>      |
>      |   |
>      |
>      +-----------------------------+----------------------------------------+
>      |
>      |
>      |                                            |
>      |
>      +-----------------------------------------...|
>      |                     IPFIX exported
>      packet                                  |
>      |
>      |                                            |
>      |
>      +-----------------------------+----------------------------------------+
>      |
>      | |                        Transport
>      Protocol                           |   |
>      |
>      +-----------------------------+----------------------------------------+
>      |
>      |
>      |                                            |
>
>      -------------------------------+--------------------------------------------+
>
>                                      |
>                                      v
>                              IPFIX export packet to collector.
>
>      (*) indicates that the block is optional.
>
>      Thanks
>      Ganesh
>
>
>

--------------19987256AD20907DA2C004EC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Tal,
<p>&nbsp;&nbsp; I agree with you that the diagram does not show the complete
interconnects.
<br>&nbsp;&nbsp; Sorry, I did not mention that this diagram is in addition
to the already existing
<br>&nbsp;&nbsp; diagram in the arch spec that shows the interconnects
which needs some
<br>&nbsp;&nbsp; modification.
<br>&nbsp;&nbsp; I was planning to just put the important functions in
the diagram and the detail
<br>&nbsp;&nbsp; text for each module would&nbsp; in the different sections.
But then maybe we need
<br>&nbsp;&nbsp; to still modify the text in the blocks.
<br>&nbsp;&nbsp; What did you mean by aggregation? Is it of flows ? There
is text in "flow recording
<br>&nbsp;&nbsp; process" which mentions about aggregate statistics. But
that has nothing to do with
<br>&nbsp;&nbsp; aggregation itself.
<br>&nbsp;&nbsp; Anonymization IMO is a protocol function and we need to
add this to the rule and
<br>&nbsp;&nbsp; function.
<p>Thanks
<br>Ganesh
<p>&nbsp;
<br>Tal Givoly wrote:
<blockquote TYPE=CITE>&nbsp;<span class=796145803-12062003><font face="Arial"><font color="#0000FF"><font size=-1>Ganesh,</font></font></font></span><span class=796145803-12062003></span><span class=796145803-12062003><font face="Arial"><font color="#0000FF"><font size=-1>Usually,
diagrams are useful for illustration of concepts, but aren't ideal for
specification. If you would like this to be a specification of the inner
workings of the metering process and exporting process, I would recommend
you add the following:</font></font></font></span><span class=796145803-12062003><font face="Arial"><font color="#0000FF"><font size=-1>-
Identification of all modules and interconnects</font></font></font></span><span class=796145803-12062003><font face="Arial"><font color="#0000FF"><font size=-1>-
Text that describes each of these modules and interconnects to disambiguate
it for the reader.</font></font></font></span><span class=796145803-12062003></span><span class=796145803-12062003><font face="Arial"><font color="#0000FF"><font size=-1>Regarding
the content itself - I believe aggregation is not clear. Also annonymization
location isn't clear.</font></font></font></span><span class=796145803-12062003></span><span class=796145803-12062003><font face="Arial"><font color="#0000FF"><font size=-1>It
seems to me to make more sense to have two distinct diagrams - one at the
high level showing MP (many to 1) -> EP. Then it would be possible to blow
up the MP and the EP independently and discuss them independently. The
EP depends primarily on the protocol features while the MP would have the
support for most of the capabilities such as timestamping, and others that
you discuss.</font></font></font></span><span class=796145803-12062003></span><span class=796145803-12062003><font face="Arial"><font color="#0000FF"><font size=-1>Tal</font></font></font></span><span class=796145803-12062003></span><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> majordomo listserver
[<A HREF="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</A>]<b>On Behalf Of </b>Ganesh Sadasivan</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Wednesday, June 11,
2003 11:58 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> ipfix@net.doit.wisc.edu</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> [ipfix] IPFIX-ARCH
: Functional flow diagram.</font></font>
<br>&nbsp;
<blockquote dir=ltr style="MARGIN-RIGHT: 0px"><tt>Hi,</tt>
<br><tt>&nbsp;&nbsp; I want to add this figure into the architecture spec.
Please go through this send</tt>
<br><tt>&nbsp;&nbsp; send any comments/corrections.</tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Packet(s) coming into Observation Point(s)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>&nbsp; +-----------------+-------------------------+&nbsp;&nbsp;
+-----+------+</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Metering Process on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Observation Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; packet header capturing&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Metering&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp; timestamping&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Process&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Observation|</tt>
<br><tt>&nbsp; |&nbsp; +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp; sampling Si (1:1 in case of no&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sampling)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; | classifying Fi (NULL when No criteria) |&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; +---------+---------------------------------+&nbsp;&nbsp;
+-----+------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flows (identified
by observation domain)&nbsp;&nbsp;&nbsp; Flows</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+--------+...</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; +-------------------------------------+----------------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Flow Recording Process(*)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | +----------------------+&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | Flow data base&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;----|Provide non-flow&nbsp; |&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | (includes flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | information (Eg. |&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | from all obs.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | router state)&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | points in an obs.&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp;&nbsp;&nbsp; |.....</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | domain)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; +------------------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;----|Maintain aggregate|&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | statistics&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | +----------------------+&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; +-------------------------------+----------------------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flow Database (identified by
observation domain)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+------------------------....</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>+-----------+-------------------------------------+--------------------------+</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Export Process&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----------------------... |</tt>
<br><tt>| +---------+------------------------------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IPFIX Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |</tt>
<br><tt>| |+---------------------------------+&nbsp; +-------------------------------+|&nbsp;&nbsp;
|</tt>
<br><tt>| || Rules for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |Functions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp; |</tt>
<br><tt>| || - Picking &amp; sending templates&nbsp;&nbsp; |&nbsp; |- Packetize
selected control&nbsp;&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| || - Picking &amp; sending data records|->|&nbsp; &amp; data
information into&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| || - Timing out flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |&nbsp; IPFIX export packet.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||...|</tt>
<br><tt>| || - Encoding template &amp; data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |- Handle export errors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp; |</tt>
<br><tt>| || - Selecting flows for export(*) |&nbsp; |- Handle timeouts
&amp; overloads&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| |+---------------------------------+&nbsp; +-------------------------------+|&nbsp;&nbsp;
|</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |</tt>
<br><tt>| +-----------------------------+----------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----------------------------------------...|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IPFIX exported packet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>| +-----------------------------+----------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Transport&nbsp; Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |</tt>
<br><tt>| +-----------------------------+----------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>+-------------------------------+--------------------------------------------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IPFIX export packet to collector.</tt>
<p><tt>(*) indicates that the block is optional.</tt>
<p><tt>Thanks</tt>
<br><tt>Ganesh</tt>
<br>&nbsp;
<br>&nbsp;</blockquote>
</blockquote>
</html>

--------------19987256AD20907DA2C004EC--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 12 10:40:34 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14118
	for <ipfix-archive@lists.ietf.org>; Thu, 12 Jun 2003 10:40:33 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QSs0-00074m-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 12 Jun 2003 09:16:04 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19QSrv-00074f-00
	for ipfix@net.doit.wisc.edu; Thu, 12 Jun 2003 09:15:59 -0500
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5CEFams015553;
	Thu, 12 Jun 2003 07:15:36 -0700 (PDT)
Received: from cisco.com (sjc-vpn3-463.cisco.com [10.21.65.207]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id HAA20161; Thu, 12 Jun 2003 07:15:33 -0700 (PDT)
Message-ID: <3EE88B04.4F0AACAD@cisco.com>
Date: Thu, 12 Jun 2003 07:15:32 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] IPFIX-ARCH : Functional flow diagram.
References: <1D3D2C371FCBD947A7897FABBD3533A502960075@xsun01.ptp.hp.com>
Content-Type: multipart/alternative;
 boundary="------------125A02AAFF7E49A36E366D87"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


--------------125A02AAFF7E49A36E366D87
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jeff,

   The template definition in the terminology does not assume any
specific structure for control info.
   (like TLV or AVP or such) and only mention that it defines the
structure and semantics of records.

   I don't know how anonymization could be an example of encoding but it
could very well be.
   Again I am not mentioning what specifically need to be done. But just
that if there are any
   rules like that it is maintained in the Protocol. Do you think we
should not mention this?

Thanks
Ganesh





"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:

>  Ganesh,  The use of templates overall is a protocol decision, keep in
> mind that other candidates, such as Diameter are not template
> oriented.  So, from an architecture perspective, I guess templates
> should not be mentioned at all, they are strictly an artifact of the
> protocol.  I don't think I follow your point regarding the second
> item, "rules for encoding".  Is anonymization an example of encoding,
> or simple translation of formats (e.g. ipaddr -> string)?  In either
> case, this sounds more protocol'ish than architecture.-- Jeff
>
>      -----Original Message-----
>      From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
>      Sent: Wednesday, June 11, 2003 2:41 PM
>      To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>      Cc: ipfix@net.doit.wisc.edu
>      Subject: Re: [ipfix] IPFIX-ARCH : Functional flow diagram.
>
>      Jeff,
>
>         - Regarding
>         "Picking & sending data records and corresponding
>      templates "
>         I  separated this out because the arch. spec does not
>      dictate the rules for sending
>         templates & corresponding data. That is more of a
>      protocol decision.
>
>         -Regarding "rules for encoding"
>         The kind of information I was thinking is if some one
>      want to use more refined encoding
>         Eg. If the flow collection is done on IP address, but the
>      address itself is encoded as
>         a "aa.bb.cc.dd" string.
>         Is this something we should be allowing to be supported
>      (as a MAY) ?
>
>      Thanks
>      Ganesh
>
>
>
>
>      "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
>
>     > Ganesh,   Nice diagram.  Maybe someday IETF will move
>     > beyond ASCII art...  But this is a fine example.   In the
>     > exporter block I would make a few modifications:| || Rules
>     > for                       |
>     > |Functions                      ||   |
>     > | ||                                 |  |- Packetize
>     > selected control   ||   |
>     > | || - Picking & sending data records|->|  & data
>     > information into      ||   |
>     > | ||    and corresponding templates  |  |  IPFIX export
>     > packet.         ||...|
>     > | || - Timing out flows              |  |- Handle export
>     > errors         ||   |
>     > | || - Selecting flows for export(*) |  |- Handle timeouts
>     > & overloads  ||   | Specifically the data record and
>     > template selections are not independent.  You cannot send
>     > out a data record w/o sending a template.  There is no
>     > reason to send a template if you will never send a data
>     > record of that form.  So, I'd merge these into one bullet
>     > point.
>     >
>     >        I removed the " " since the function already
>     >      states "packetize control and data into export
>     >      packets".  The rules seem to imply a level of
>     >      configurability of encoding which I don't think
>     >      exists.Regards,  Jeff Meyer
>     >
>     >      -----Original Message-----
>     >      From: Ganesh Sadasivan
>     >      [mailto:gsadasiv@cisco.com]
>     >      Sent: Wednesday, June 11, 2003 11:58 AM
>     >      To: ipfix@net.doit.wisc.edu
>     >      Subject: [ipfix] IPFIX-ARCH : Functional flow
>     >      diagram.
>     >
>     >      Hi,
>     >         I want to add this figure into the
>     >      architecture spec. Please go through this send
>     >         send any comments/corrections.
>     >
>     >                          Packet(s) coming into
>     >      Observation Point(s)
>     >
>     >      |                                   |
>     >
>     >      |                                   |
>     >
>     >      v                                   v
>     >
>     >      +-----------------+-------------------------+
>     >      +-----+------+
>     >        |           Metering Process on an
>     >      |   |            |
>     >        |              Observation Point
>     >      |   |            |
>     >        |  packet header capturing
>     >      |   |            |
>     >        |         |
>     >      |   | Metering   |
>     >        |    timestamping
>     >      |   | Process    |
>     >        |         |
>     >      |   | on an      |
>     >        |         v
>     >      |   | Observation|
>     >        |  +------+
>     >      |   | Point      |
>     >        |  |      |
>     >      |   |            |
>     >        |  |   sampling Si (1:1 in case of no
>     >      |   |            |
>     >        |  |      |          sampling)
>     >      |   |            |
>     >        |  | classifying Fi (NULL when No criteria)
>     >      |   |            |
>     >        |  |      |
>     >      |   |            |
>     >        |  +------+
>     >      |   |            |
>     >        |         |
>     >      |   |            |
>     >
>     >      +---------+---------------------------------+
>     >      +-----+------+
>     >
>     >      |                                           |
>     >                Flows (identified by observation
>     >      domain)    Flows
>     >
>     >      +----...
>     >      +--------+...
>     >
>     >      |                                           v
>     >                  |
>     >      +-------------------------------------+----------------+
>     >
>     >                  |     |             Flow Recording
>     >      Process(*)                |
>     >                  |     | +----------------------+
>     >      +------------------+    |
>     >                  |     | | Flow data base
>     >      |<----|Provide non-flow  |    |
>     >                  |     | | (includes flows      |
>     >      | information (Eg. |    |
>     >                  |     | | from all obs.        |
>     >      | router state)    |    |
>     >                  |     | | points in an obs.    |
>     >      +------------------+    |.....
>     >                  |     | | domain)
>     >      |                             |
>     >                  |     | |                      |
>     >      +------------------+    |
>     >                  |     | |
>     >      |<----|Maintain aggregate|    |
>     >                  |     | |                      |
>     >      | statistics       |    |
>     >                  |     | +----------------------+
>     >      +------------------+    |
>     >                  |
>     >      +-------------------------------+----------------------+
>     >
>     >
>     >      |                                     |
>     >                  |        Flow Database (identified
>     >      by observation domain)
>     >
>     >      |
>     >      +------------------------....
>     >
>     >      v                                     v
>     >
>     >      -----------+-------------------------------------+--------------------------+
>     >
>     >      |           |            Export
>     >      Process           |                          |
>     >      |
>     >      |
>     >      +----------------------... |
>     >      |
>     >      +---------+------------------------------------------------------------+
>     >      |
>     >      | |         v                  IPFIX
>     >      Protocol                            |   |
>     >      | |+---------------------------------+
>     >      +-------------------------------+|   |
>     >      | || Rules for                       |
>     >      |Functions                      ||   |
>     >      | || - Picking & sending templates   |  |-
>     >      Packetize selected control   ||   |
>     >      | || - Picking & sending data records|->|  &
>     >      data information into      ||   |
>     >      | || - Timing out flows              |  |  IPFIX
>     >      export packet.         ||...|
>     >      | || - Encoding template & data      |  |-
>     >      Handle export errors         ||   |
>     >      | || - Selecting flows for export(*) |  |-
>     >      Handle timeouts & overloads  ||   |
>     >      | |+---------------------------------+
>     >      +-------------------------------+|   |
>     >      |
>     >      |
>     >      |   |
>     >      |
>     >      +-----------------------------+----------------------------------------+
>     >      |
>     >      |
>     >      |                                            |
>     >      |
>     >      +-----------------------------------------...|
>     >      |                     IPFIX exported
>     >      packet                                  |
>     >      |
>     >      |                                            |
>     >      |
>     >      +-----------------------------+----------------------------------------+
>     >      |
>     >      | |                        Transport
>     >      Protocol                           |   |
>     >      |
>     >      +-----------------------------+----------------------------------------+
>     >      |
>     >      |
>     >      |                                            |
>     >
>     >      -------------------------------+--------------------------------------------+
>     >
>     >                                      |
>     >                                      v
>     >                              IPFIX export packet to
>     >      collector.
>     >
>     >      (*) indicates that the block is optional.
>     >
>     >      Thanks
>     >      Ganesh
>     >
>     >
>     >

--------------125A02AAFF7E49A36E366D87
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Jeff,
<p>&nbsp;&nbsp; The template definition in the terminology does not assume
any specific structure for control info.
<br>&nbsp;&nbsp; (like TLV or AVP or such) and only mention that it defines
the structure and semantics of records.
<p>&nbsp;&nbsp; I don't know how <font color="#000000">anonymization could
be an example of encoding but it could very well be.</font>
<br><font color="#000000">&nbsp;&nbsp; Again I am not mentioning what specifically
need to be done. But just that if there are any</font>
<br><font color="#000000">&nbsp;&nbsp; rules like that it is maintained
in the Protocol. Do you think we should not mention this?</font><font color="#000000"></font>
<p><font color="#000000">Thanks</font>
<br><font color="#000000">Ganesh</font>
<br><font color="#000000"></font>&nbsp;
<br><font color="#000000"></font>&nbsp;
<p>&nbsp;&nbsp;&nbsp;
<p>"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
<blockquote TYPE=CITE>&nbsp;<span class=656344723-11062003><font face="Arial"><font color="#0000FF"><font size=-1>Ganesh,</font></font></font></span><span class=656344723-11062003></span><span class=656344723-11062003><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;
The use of templates overall is a protocol decision, keep in mind that
other candidates, such as Diameter are not template oriented.&nbsp; So,
from an architecture perspective, I guess templates should not be mentioned
at all, they are strictly an artifact of the protocol.</font></font></font></span><span class=656344723-11062003></span><span class=656344723-11062003><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;
I don't think I follow your point regarding the second item, "rules for
encoding".&nbsp; Is anonymization an example of encoding, or simple translation
of formats (e.g. ipaddr -> string)?&nbsp; In either case, this sounds more
protocol'ish than architecture.</font></font></font></span><span class=656344723-11062003></span><span class=656344723-11062003><font face="Arial"><font color="#0000FF"><font size=-1>--
Jeff</font></font></font></span>
<blockquote dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Ganesh Sadasivan [<A HREF="mailto:gsadasiv@cisco.com">mailto:gsadasiv@cisco.com</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Wednesday, June 11,
2003 2:41 PM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> MEYER,JEFFREY D (HP-Cupertino,ex1)</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> ipfix@net.doit.wisc.edu</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> Re: [ipfix] IPFIX-ARCH
: Functional flow diagram.</font></font>
<br>&nbsp;</div>
Jeff,
<p>&nbsp;&nbsp; - Regarding
<br>&nbsp;&nbsp; "P<tt>icking &amp; sending data records and corresponding
templates "</tt>
<br>&nbsp;&nbsp; I&nbsp; separated this out because the arch. spec does
not dictate the rules for sending
<br>&nbsp;&nbsp; templates &amp; corresponding data. That is more of a
protocol decision.
<p>&nbsp;&nbsp; -Regarding "<font face="Arial"><font color="#000000"><font size=-1>rules
for encoding"</font></font></font>
<br><font color="#000000"><font face="Arial"><font size=-1>&nbsp;&nbsp;
</font></font>The kind of information I was thinking is if some one want
to use more refined encoding</font>
<br><font color="#000000">&nbsp;&nbsp; Eg. If the flow collection is done
on IP address, but the address itself is encoded as</font>
<br><font color="#000000">&nbsp;&nbsp; a "aa.bb.cc.dd" string.</font>
<br><font color="#000000">&nbsp;&nbsp; Is this something we should be allowing
to be supported (as a MAY) ?</font>
<p><font face="Arial"><font color="#000000"><font size=-1>Thanks</font></font></font>
<br><font face="Arial"><font color="#000000"><font size=-1>Ganesh</font></font></font>
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p>"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
<blockquote TYPE="CITE"><span class=046484219-11062003><font face="Arial"><font color="#0000FF"><font size=-1>Ganesh,</span><span 
    class=046484219-11062003></span><span class=046484219-11062003>&nbsp;&nbsp;
Nice diagram.&nbsp; Maybe someday IETF will move beyond ASCII art...&nbsp;
But this is a fine example.</span><span 
    class=046484219-11062003></span><span class=046484219-11062003>&nbsp;&nbsp;
In the exporter block I would make a few modifications:</span><span 
    class=046484219-11062003></span><span class=046484219-11062003></font></font></font><font face="Courier New">|
|| Rules for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |Functions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp; |</font>
<br><tt>| ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |- Packetize selected control&nbsp;&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| || - Picking &amp; sending&nbsp;</span><span 
    class=046484219-11062003>data
records|->|&nbsp; &amp; data information into&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp; |</tt>
<br><tt>| ||&nbsp;&nbsp;&nbsp; and corresponding templates&nbsp; |&nbsp;
|&nbsp; IPFIX export packet.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||...|</tt>
<br><tt>| || - Timing out flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |- Handle export errors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp; |</tt>
<br><tt>| || - Selecting flows for export(*) |&nbsp; |- Handle timeouts
&amp; overloads&nbsp; ||&nbsp;&nbsp; |</span><span 
    class=046484219-11062003></span><span class=046484219-11062003></tt><font face="Courier New">
</font><font face="Arial"><font color="#0000FF"><font size=-1>Specifically
the data record and template selections are not independent.&nbsp; You
cannot send out a data record w/o sending a template.&nbsp; There is no
reason to send a template if you will never send a data record of that
form.&nbsp; So, I'd merge these into one bullet point.</font></font></font>
<blockquote dir=ltr 
    style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<div class=OutlookMessageHeader dir=ltr><span 
      class=046484219-11062003><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;
I removed the " " since the function already states "packetize control
and data into export packets".&nbsp; The rules seem to imply a level of
configurability of encoding which I don't think exists.</span><span 
      class=046484219-11062003></span><span class=046484219-11062003>Regards,</span><span 
      class=046484219-11062003></span><span class=046484219-11062003>&nbsp;
Jeff Meyer</font></font></font></span>
<p><font face="Tahoma"><font size=-1>-----Original Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Ganesh Sadasivan [<a href="mailto:gsadasiv@cisco.com">mailto:gsadasiv@cisco.com</a>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Wednesday, June 11,
2003 11:58 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> ipfix@net.doit.wisc.edu</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> [ipfix] IPFIX-ARCH
: Functional flow diagram.</font></font>
<br>&nbsp;</div>
<tt>Hi,</tt>
<br><tt>&nbsp;&nbsp; I want to add this figure into the architecture spec.
Please go through this send</tt>
<br><tt>&nbsp;&nbsp; send any comments/corrections.</tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Packet(s) coming into Observation Point(s)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>&nbsp; +-----------------+-------------------------+&nbsp;&nbsp;
+-----+------+</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Metering Process on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Observation Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; packet header capturing&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Metering&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp; timestamping&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Process&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Observation|</tt>
<br><tt>&nbsp; |&nbsp; +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp; sampling Si (1:1 in case of no&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sampling)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; | classifying Fi (NULL when No criteria) |&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; +---------+---------------------------------+&nbsp;&nbsp;
+-----+------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flows (identified
by observation domain)&nbsp;&nbsp;&nbsp; Flows</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+--------+...</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; +-------------------------------------+----------------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Flow Recording Process(*)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | +----------------------+&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | Flow data base&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;----|Provide non-flow&nbsp; |&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | (includes flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | information (Eg. |&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | from all obs.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | router state)&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | points in an obs.&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp;&nbsp;&nbsp; |.....</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | domain)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; +------------------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;----|Maintain aggregate|&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | statistics&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | +----------------------+&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; +-------------------------------+----------------------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flow Database (identified by
observation domain)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+------------------------....</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>+-----------+-------------------------------------+--------------------------+</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Export Process&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----------------------... |</tt>
<br><tt>| +---------+------------------------------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IPFIX Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |</tt>
<br><tt>| |+---------------------------------+&nbsp; +-------------------------------+|&nbsp;&nbsp;
|</tt>
<br><tt>| || Rules for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |Functions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp; |</tt>
<br><tt>| || - Picking &amp; sending templates&nbsp;&nbsp; |&nbsp; |- Packetize
selected control&nbsp;&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| || - Picking &amp; sending data records|->|&nbsp; &amp; data
information into&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| || - Timing out flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |&nbsp; IPFIX export packet.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||...|</tt>
<br><tt>| || - Encoding template &amp; data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |- Handle export errors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp; |</tt>
<br><tt>| || - Selecting flows for export(*) |&nbsp; |- Handle timeouts
&amp; overloads&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| |+---------------------------------+&nbsp; +-------------------------------+|&nbsp;&nbsp;
|</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |</tt>
<br><tt>| +-----------------------------+----------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----------------------------------------...|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IPFIX exported packet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>| +-----------------------------+----------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Transport&nbsp; Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |</tt>
<br><tt>| +-----------------------------+----------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>+-------------------------------+--------------------------------------------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IPFIX export packet to collector.</tt>
<p><tt>(*) indicates that the block is optional.</tt>
<p><tt>Thanks</tt>
<br><tt>Ganesh</tt>
<br>&nbsp;
<br>&nbsp;</blockquote>
</blockquote>
</blockquote>
</span></blockquote>
</html>

--------------125A02AAFF7E49A36E366D87--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 12 12:24:36 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17474
	for <ipfix-archive@lists.ietf.org>; Thu, 12 Jun 2003 12:24:35 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QUYB-0002Ct-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 12 Jun 2003 11:03:43 -0500
Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QUYA-0002Co-00
	for ipfix@net.doit.wisc.edu; Thu, 12 Jun 2003 11:03:42 -0500
Date: Thu, 12 Jun 2003 11:03:42 -0500
From: Dave Plonka <plonka@doit.wisc.edu>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] I-D ACTION:draft-ietf-ipfix-reqs-10.txt
Message-ID: <20030612110342.B2108@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
X-Organization: University of Wisconsin-Madison, DoIT Network Services
X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL)
X-URL: http://net.doit.wisc.edu/~plonka/
X-VMS-Error: %SYSTEM-W-SUBRNG6, subscript 6 range error, PC=00000000, PS=00000598
X-Shakespearean-Insult: Thou impertinent milk-livered puttock
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


IPFIX folks,

Below please find the announcement regarding the availability of the
updated requirements draft.

The following link to it now appears on the IPFIX web site index:

   http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-10.txt

Its also mirrored here:

   http://ipfix.doit.wisc.edu/req/draft-ietf-ipfix-reqs-10.txt

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-10.txt
Date: Thu, 12 Jun 2003 07:19:15 -0400
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-10.txt
	Pages		: 31
	Date		: 2003-6-11
	
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-10.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-10.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-10.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:	<2003-6-11134733.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipfix-reqs-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipfix-reqs-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-6-11134733.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  Thu Jun 12 14:50:28 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22738
	for <ipfix-archive@lists.ietf.org>; Thu, 12 Jun 2003 14:50:28 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QWwK-0006B8-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 12 Jun 2003 13:36:48 -0500
Received: from atlrel9.hp.com ([156.153.255.214])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19QWwI-0006B0-00
	for ipfix@net.doit.wisc.edu; Thu, 12 Jun 2003 13:36:46 -0500
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel9.hp.com (Postfix) with ESMTP
	id 265E31C0137B; Thu, 12 Jun 2003 14:36:46 -0400 (EDT)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP
	id 0FA491C000A1; Thu, 12 Jun 2003 14:36:46 -0400 (EDT)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <MZDTH592>; Thu, 12 Jun 2003 14:36:45 -0400
Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50296007F@xsun01.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ganesh Sadasivan'" <gsadasiv@cisco.com>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
Cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] IPFIX-ARCH : Functional flow diagram.
Date: Thu, 12 Jun 2003 14:36:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C33111.8D0AB4C0"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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_01C33111.8D0AB4C0
Content-Type: text/plain;
	charset="iso-8859-1"

Ganesh,
 
  I see now that template is mentioned in the original arch document as an
abstract concept identifying the information items to be preserved when
monitoring various flows.  
 
  I'm still unclear on the separation of "rules for encoding" and "function
of packetizing data", they sound like the same thing to me.  But, maybe it
will be clearer in the overall context of the revised document.
 
Regards,
 
  Jeff Meyer

-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Thursday, June 12, 2003 7:16 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] IPFIX-ARCH : Functional flow diagram.


Jeff, 

   The template definition in the terminology does not assume any specific
structure for control info. 
   (like TLV or AVP or such) and only mention that it defines the structure
and semantics of records. 


   I don't know how anonymization could be an example of encoding but it
could very well be. 
   Again I am not mentioning what specifically need to be done. But just
that if there are any 
   rules like that it is maintained in the Protocol. Do you think we should
not mention this? 


Thanks 
Ganesh 
  
  


    


"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote: 


 Ganesh,  The use of templates overall is a protocol decision, keep in mind
that other candidates, such as Diameter are not template oriented.  So, from
an architecture perspective, I guess templates should not be mentioned at
all, they are strictly an artifact of the protocol.  I don't think I follow
your point regarding the second item, "rules for encoding".  Is
anonymization an example of encoding, or simple translation of formats (e.g.
ipaddr -> string)?  In either case, this sounds more protocol'ish than
architecture.-- Jeff 

-----Original Message----- 
From: Ganesh Sadasivan [ mailto:gsadasiv@cisco.com
<mailto:gsadasiv@cisco.com> ] 
Sent: Wednesday, June 11, 2003 2:41 PM 
To: MEYER,JEFFREY D (HP-Cupertino,ex1) 
Cc: ipfix@net.doit.wisc.edu 
Subject: Re: [ipfix] IPFIX-ARCH : Functional flow diagram. 
 
Jeff, 

   - Regarding 
   "Picking & sending data records and corresponding templates " 
   I  separated this out because the arch. spec does not dictate the rules
for sending 
   templates & corresponding data. That is more of a protocol decision. 


   -Regarding "rules for encoding" 
   The kind of information I was thinking is if some one want to use more
refined encoding 
   Eg. If the flow collection is done on IP address, but the address itself
is encoded as 
   a "aa.bb.cc.dd" string. 
   Is this something we should be allowing to be supported (as a MAY) ? 


Thanks 
Ganesh 
  
  
  


"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote: 


Ganesh,   Nice diagram.  Maybe someday IETF will move beyond ASCII art...
But this is a fine example.   In the exporter block I would make a few
modifications:| || Rules for                       |  |Functions
||   | 
| ||                                 |  |- Packetize selected control   ||
| 
| || - Picking & sending data records|->|  & data information into      ||
| 
| ||    and corresponding templates  |  |  IPFIX export packet.
||...| 
| || - Timing out flows              |  |- Handle export errors         ||
| 
| || - Selecting flows for export(*) |  |- Handle timeouts & overloads  ||
| Specifically the data record and template selections are not independent.
You cannot send out a data record w/o sending a template.  There is no
reason to send a template if you will never send a data record of that form.
So, I'd merge these into one bullet point. 

  I removed the " " since the function already states "packetize control and
data into export packets".  The rules seem to imply a level of
configurability of encoding which I don't think exists.Regards,  Jeff Meyer 

-----Original Message----- 
From: Ganesh Sadasivan [ mailto:gsadasiv@cisco.com
<mailto:gsadasiv@cisco.com> ] 
Sent: Wednesday, June 11, 2003 11:58 AM 
To: ipfix@net.doit.wisc.edu 
Subject: [ipfix] IPFIX-ARCH : Functional flow diagram. 
 

Hi, 
   I want to add this figure into the architecture spec. Please go through
this send 
   send any comments/corrections. 

                    Packet(s) coming into Observation Point(s) 
                    |                                   | 
                    |                                   | 
                    v                                   v 
  +-----------------+-------------------------+   +-----+------+ 
  |           Metering Process on an          |   |            | 
  |              Observation Point            |   |            | 
  |  packet header capturing                  |   |            | 
  |         |                                 |   | Metering   | 
  |    timestamping                           |   | Process    | 
  |         |                                 |   | on an      | 
  |         v                                 |   | Observation| 
  |  +------+                                 |   | Point      | 
  |  |      |                                 |   |            | 
  |  |   sampling Si (1:1 in case of no       |   |            | 
  |  |      |          sampling)              |   |            | 
  |  | classifying Fi (NULL when No criteria) |   |            | 
  |  |      |                                 |   |            | 
  |  +------+                                 |   |            | 
  |         |                                 |   |            | 
  +---------+---------------------------------+   +-----+------+ 
            |                                           | 
          Flows (identified by observation domain)    Flows 
            +----...                                    +--------+... 
            |                                           v 
            |     +-------------------------------------+----------------+ 
            |     |             Flow Recording Process(*)                | 
            |     | +----------------------+     +------------------+    | 
            |     | | Flow data base       |<----|Provide non-flow  |    | 
            |     | | (includes flows      |     | information (Eg. |    | 
            |     | | from all obs.        |     | router state)    |    | 
            |     | | points in an obs.    |     +------------------+
|..... 
            |     | | domain)              |                             | 
            |     | |                      |     +------------------+    | 
            |     | |                      |<----|Maintain aggregate|    | 
            |     | |                      |     | statistics       |    | 
            |     | +----------------------+     +------------------+    | 
            |     +-------------------------------+----------------------+ 
            |                                     | 
            |        Flow Database (identified by observation domain) 
            |
+------------------------.... 
            v                                     v 
+-----------+-------------------------------------+-------------------------
-+ 
|           |            Export Process           |
| 
|           |                                     +----------------------...
| 
| +---------+------------------------------------------------------------+
| 
| |         v                  IPFIX Protocol                            |
| 
| |+---------------------------------+  +-------------------------------+|
| 
| || Rules for                       |  |Functions                      ||
| 
| || - Picking & sending templates   |  |- Packetize selected control   ||
| 
| || - Picking & sending data records|->|  & data information into      ||
| 
| || - Timing out flows              |  |  IPFIX export packet.
||...| 
| || - Encoding template & data      |  |- Handle export errors         ||
| 
| || - Selecting flows for export(*) |  |- Handle timeouts & overloads  ||
| 
| |+---------------------------------+  +-------------------------------+|
| 
| |                                                                      |
| 
| +-----------------------------+----------------------------------------+
| 
|                               |
| 
|
+-----------------------------------------...| 
|                     IPFIX exported packet
| 
|                               |
| 
| +-----------------------------+----------------------------------------+
| 
| |                        Transport  Protocol                           |
| 
| +-----------------------------+----------------------------------------+
| 
|                               |
| 
+-------------------------------+-------------------------------------------
-+ 
                                | 
                                v 
                        IPFIX export packet to collector. 


(*) indicates that the block is optional. 


Thanks 
Ganesh 
  
 


------_=_NextPart_001_01C33111.8D0AB4C0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4915.500" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=093163018-12062003><FONT face=Arial color=#0000ff 
size=2>Ganesh,</FONT></SPAN></DIV>
<DIV><SPAN class=093163018-12062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=093163018-12062003><FONT face=Arial color=#0000ff size=2>&nbsp; 
I see now that template is mentioned in the original arch document as an 
abstract concept identifying the information items to be preserved when 
monitoring various flows.&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=093163018-12062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=093163018-12062003><FONT face=Arial color=#0000ff size=2>&nbsp; 
I'm still unclear on the separation of "rules for encoding" and "function of 
packetizing data", they sound like the same thing to me.&nbsp; But, maybe it 
will be clearer in the overall context of the revised 
document.</FONT></SPAN></DIV>
<DIV><SPAN class=093163018-12062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=093163018-12062003><FONT face=Arial color=#0000ff 
size=2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=093163018-12062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=093163018-12062003><FONT face=Arial color=#0000ff size=2>&nbsp; 
Jeff Meyer</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Ganesh Sadasivan 
  [mailto:gsadasiv@cisco.com]<BR><B>Sent:</B> Thursday, June 12, 2003 7:16 
  AM<BR><B>To:</B> MEYER,JEFFREY D (HP-Cupertino,ex1)<BR><B>Cc:</B> 
  ipfix@net.doit.wisc.edu<BR><B>Subject:</B> Re: [ipfix] IPFIX-ARCH : Functional 
  flow diagram.<BR><BR></FONT></DIV>Jeff, 
  <P>&nbsp;&nbsp; The template definition in the terminology does not assume any 
  specific structure for control info. <BR>&nbsp;&nbsp; (like TLV or AVP or 
  such) and only mention that it defines the structure and semantics of records. 

  <P>&nbsp;&nbsp; I don't know how <FONT color=#000000>anonymization could be an 
  example of encoding but it could very well be.</FONT> <BR><FONT 
  color=#000000>&nbsp;&nbsp; Again I am not mentioning what specifically need to 
  be done. But just that if there are any</FONT> <BR><FONT 
  color=#000000>&nbsp;&nbsp; rules like that it is maintained in the Protocol. 
  Do you think we should not mention this?</FONT><FONT color=#000000></FONT> 
  <P><FONT color=#000000>Thanks</FONT> <BR><FONT color=#000000>Ganesh</FONT> 
  <BR><FONT color=#000000></FONT>&nbsp; <BR><FONT color=#000000></FONT>&nbsp; 
  <P>&nbsp;&nbsp;&nbsp; 
  <P>"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote: 
  <BLOCKQUOTE TYPE="CITE">&nbsp;<SPAN class=656344723-11062003><FONT 
    face=Arial><FONT color=#0000ff><FONT 
    size=-1>Ganesh,</FONT></FONT></FONT></SPAN><SPAN 
    class=656344723-11062003></SPAN><SPAN class=656344723-11062003><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>&nbsp; The use of templates 
    overall is a protocol decision, keep in mind that other candidates, such as 
    Diameter are not template oriented.&nbsp; So, from an architecture 
    perspective, I guess templates should not be mentioned at all, they are 
    strictly an artifact of the protocol.</FONT></FONT></FONT></SPAN><SPAN 
    class=656344723-11062003></SPAN><SPAN class=656344723-11062003><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>&nbsp; I don't think I follow 
    your point regarding the second item, "rules for encoding".&nbsp; Is 
    anonymization an example of encoding, or simple translation of formats (e.g. 
    ipaddr -&gt; string)?&nbsp; In either case, this sounds more protocol'ish 
    than architecture.</FONT></FONT></FONT></SPAN><SPAN 
    class=656344723-11062003></SPAN><SPAN class=656344723-11062003><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>-- 
    Jeff</FONT></FONT></FONT></SPAN> 
    <BLOCKQUOTE dir=ltr 
    style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
      <DIV class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT 
      size=-1>-----Original Message-----</FONT></FONT> <BR><FONT 
      face=Tahoma><FONT size=-1><B>From:</B> Ganesh Sadasivan [<A 
      href="mailto:gsadasiv@cisco.com">mailto:gsadasiv@cisco.com</A>]</FONT></FONT> 
      <BR><FONT face=Tahoma><FONT size=-1><B>Sent:</B> Wednesday, June 11, 2003 
      2:41 PM</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>To:</B> 
      MEYER,JEFFREY D (HP-Cupertino,ex1)</FONT></FONT> <BR><FONT 
      face=Tahoma><FONT size=-1><B>Cc:</B> ipfix@net.doit.wisc.edu</FONT></FONT> 
      <BR><FONT face=Tahoma><FONT size=-1><B>Subject:</B> Re: [ipfix] IPFIX-ARCH 
      : Functional flow diagram.</FONT></FONT> <BR>&nbsp;</DIV>Jeff, 
      <P>&nbsp;&nbsp; - Regarding <BR>&nbsp;&nbsp; "P<TT>icking &amp; sending 
      data records and corresponding templates "</TT> <BR>&nbsp;&nbsp; I&nbsp; 
      separated this out because the arch. spec does not dictate the rules for 
      sending <BR>&nbsp;&nbsp; templates &amp; corresponding data. That is more 
      of a protocol decision. 
      <P>&nbsp;&nbsp; -Regarding "<FONT face=Arial><FONT color=#000000><FONT 
      size=-1>rules for encoding"</FONT></FONT></FONT> <BR><FONT 
      color=#000000><FONT face=Arial><FONT size=-1>&nbsp;&nbsp; 
      </FONT></FONT>The kind of information I was thinking is if some one want 
      to use more refined encoding</FONT> <BR><FONT color=#000000>&nbsp;&nbsp; 
      Eg. If the flow collection is done on IP address, but the address itself 
      is encoded as</FONT> <BR><FONT color=#000000>&nbsp;&nbsp; a "aa.bb.cc.dd" 
      string.</FONT> <BR><FONT color=#000000>&nbsp;&nbsp; Is this something we 
      should be allowing to be supported (as a MAY) ?</FONT> 
      <P><FONT face=Arial><FONT color=#000000><FONT 
      size=-1>Thanks</FONT></FONT></FONT> <BR><FONT face=Arial><FONT 
      color=#000000><FONT size=-1>Ganesh</FONT></FONT></FONT> <BR>&nbsp; 
      <BR>&nbsp; <BR>&nbsp; 
      <P>"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote: 
      <BLOCKQUOTE TYPE="CITE"><SPAN class=046484219-11062003><FONT 
        face=Arial><FONT color=#0000ff><FONT size=-1>Ganesh,</SPAN><SPAN 
        class=046484219-11062003></SPAN><SPAN 
        class=046484219-11062003>&nbsp;&nbsp; Nice diagram.&nbsp; Maybe someday 
        IETF will move beyond ASCII art...&nbsp; But this is a fine 
        example.</SPAN><SPAN class=046484219-11062003></SPAN><SPAN 
        class=046484219-11062003>&nbsp;&nbsp; In the exporter block I would make 
        a few modifications:</SPAN><SPAN class=046484219-11062003></SPAN><SPAN 
        class=046484219-11062003></FONT></FONT></FONT><FONT face="Courier New">| 
        || Rules 
        for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        |&nbsp; 
        |Functions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        ||&nbsp;&nbsp; |</FONT> <BR><TT>| 
        ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        |&nbsp; |- Packetize selected control&nbsp;&nbsp; ||&nbsp;&nbsp; |</TT> 
        <BR><TT>| || - Picking &amp; sending&nbsp;</SPAN><SPAN 
        class=046484219-11062003>data records|-&gt;|&nbsp; &amp; data 
        information into&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp; |</TT> 
        <BR><TT>| ||&nbsp;&nbsp;&nbsp; and corresponding templates&nbsp; |&nbsp; 
        |&nbsp; IPFIX export 
        packet.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||...|</TT> 
        <BR><TT>| || - Timing out 
        flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        |&nbsp; |- Handle export 
        errors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp; 
        |</TT> <BR><TT>| || - Selecting flows for export(*) |&nbsp; |- Handle 
        timeouts &amp; overloads&nbsp; ||&nbsp;&nbsp; |</SPAN><SPAN 
        class=046484219-11062003></SPAN><SPAN 
        class=046484219-11062003></TT><FONT face="Courier New"> </FONT><FONT 
        face=Arial><FONT color=#0000ff><FONT size=-1>Specifically the data 
        record and template selections are not independent.&nbsp; You cannot 
        send out a data record w/o sending a template.&nbsp; There is no reason 
        to send a template if you will never send a data record of that 
        form.&nbsp; So, I'd merge these into one bullet 
        point.</FONT></FONT></FONT> 
        <BLOCKQUOTE dir=ltr 
        style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
          <DIV class=OutlookMessageHeader dir=ltr><SPAN 
          class=046484219-11062003><FONT face=Arial><FONT color=#0000ff><FONT 
          size=-1>&nbsp; I removed the " " since the function already states 
          "packetize control and data into export packets".&nbsp; The rules seem 
          to imply a level of configurability of encoding which I don't think 
          exists.</SPAN><SPAN class=046484219-11062003></SPAN><SPAN 
          class=046484219-11062003>Regards,</SPAN><SPAN 
          class=046484219-11062003></SPAN><SPAN class=046484219-11062003>&nbsp; 
          Jeff Meyer</FONT></FONT></FONT></SPAN> 
          <P><FONT face=Tahoma><FONT size=-1>-----Original 
          Message-----</FONT></FONT> <BR><FONT face=Tahoma><FONT 
          size=-1><B>From:</B> Ganesh Sadasivan [<A 
          href="mailto:gsadasiv@cisco.com">mailto:gsadasiv@cisco.com</A>]</FONT></FONT> 
          <BR><FONT face=Tahoma><FONT size=-1><B>Sent:</B> Wednesday, June 11, 
          2003 11:58 AM</FONT></FONT> <BR><FONT face=Tahoma><FONT 
          size=-1><B>To:</B> ipfix@net.doit.wisc.edu</FONT></FONT> <BR><FONT 
          face=Tahoma><FONT size=-1><B>Subject:</B> [ipfix] IPFIX-ARCH : 
          Functional flow diagram.</FONT></FONT> 
          <BR>&nbsp;</P></DIV><TT>Hi,</TT> <BR><TT>&nbsp;&nbsp; I want to add 
          this figure into the architecture spec. Please go through this 
          send</TT> <BR><TT>&nbsp;&nbsp; send any comments/corrections.</TT> 
          <P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Packet(s) coming into Observation Point(s)</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          v</TT> <BR><TT>&nbsp; 
          +-----------------+-------------------------+&nbsp;&nbsp; 
          +-----+------+</TT> <BR><TT>&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Metering 
          Process on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Observation 
          Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>&nbsp; |&nbsp; packet header 
          capturing&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp; | Metering&nbsp;&nbsp; |</TT> <BR><TT>&nbsp; 
          |&nbsp;&nbsp;&nbsp; 
          timestamping&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp; | Process&nbsp;&nbsp;&nbsp; |</TT> <BR><TT>&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp; | on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
          <BR><TT>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp; | Observation|</TT> <BR><TT>&nbsp; |&nbsp; 
          +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp; | Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
          <BR><TT>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>&nbsp; |&nbsp; |&nbsp;&nbsp; sampling Si (1:1 in case 
          of no&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          sampling)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>&nbsp; |&nbsp; | classifying Fi (NULL when No criteria) 
          |&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>&nbsp; |&nbsp; 
          +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>&nbsp; 
          +---------+---------------------------------+&nbsp;&nbsp; 
          +-----+------+</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Flows (identified by observation domain)&nbsp;&nbsp;&nbsp; Flows</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          +----...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          +--------+...</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          v</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; 
          +-------------------------------------+----------------+</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Flow Recording 
          Process(*)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; | 
          +----------------------+&nbsp;&nbsp;&nbsp;&nbsp; 
          +------------------+&nbsp;&nbsp;&nbsp; |</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; | | Flow data 
          base&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&lt;----|Provide 
          non-flow&nbsp; |&nbsp;&nbsp;&nbsp; |</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; | | (includes 
          flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; | 
          information (Eg. |&nbsp;&nbsp;&nbsp; |</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; | | from all 
          obs.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; | router state)&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp; |</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; | | points in an obs.&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; +------------------+&nbsp;&nbsp;&nbsp; 
          |.....</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; | | 
          domain)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; | 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; +------------------+&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; | 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&lt;----|Maintain aggregate|&nbsp;&nbsp;&nbsp; |</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; | 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; | 
          statistics&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; | 
          +----------------------+&nbsp;&nbsp;&nbsp;&nbsp; 
          +------------------+&nbsp;&nbsp;&nbsp; |</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp; 
          +-------------------------------+----------------------+</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flow Database (identified 
          by observation domain)</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          +------------------------....</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          v</TT> 
          <BR><TT>+-----------+-------------------------------------+--------------------------+</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Export 
          Process&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          +----------------------... |</TT> <BR><TT>| 
          +---------+------------------------------------------------------------+&nbsp;&nbsp; 
          |</TT> <BR><TT>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          IPFIX 
          Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp; |</TT> <BR><TT>| 
          |+---------------------------------+&nbsp; 
          +-------------------------------+|&nbsp;&nbsp; |</TT> <BR><TT>| || 
          Rules 
          for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp; 
          |Functions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          ||&nbsp;&nbsp; |</TT> <BR><TT>| || - Picking &amp; sending 
          templates&nbsp;&nbsp; |&nbsp; |- Packetize selected 
          control&nbsp;&nbsp; ||&nbsp;&nbsp; |</TT> <BR><TT>| || - Picking &amp; 
          sending data records|-&gt;|&nbsp; &amp; data information 
          into&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp; |</TT> <BR><TT>| || 
          - Timing out 
          flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp; |&nbsp; IPFIX export 
          packet.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||...|</TT> 
          <BR><TT>| || - Encoding template &amp; 
          data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; |- Handle export 
          errors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp; 
          |</TT> <BR><TT>| || - Selecting flows for export(*) |&nbsp; |- Handle 
          timeouts &amp; overloads&nbsp; ||&nbsp;&nbsp; |</TT> <BR><TT>| 
          |+---------------------------------+&nbsp; 
          +-------------------------------+|&nbsp;&nbsp; |</TT> <BR><TT>| 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp; |</TT> <BR><TT>| 
          +-----------------------------+----------------------------------------+&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          +-----------------------------------------...|</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          IPFIX exported 
          packet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>| 
          +-----------------------------+----------------------------------------+&nbsp;&nbsp; 
          |</TT> <BR><TT>| 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Transport&nbsp; 
          Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp; |</TT> <BR><TT>| 
          +-----------------------------+----------------------------------------+&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>+-------------------------------+--------------------------------------------+</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          v</TT> 
          <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          IPFIX export packet to collector.</TT> 
          <P><TT>(*) indicates that the block is optional.</TT> 
          <P><TT>Thanks</TT> <BR><TT>Ganesh</TT> <BR>&nbsp; 
        <BR>&nbsp;</P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></SPAN></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C33111.8D0AB4C0--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 12 15:16:17 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24547
	for <ipfix-archive@lists.ietf.org>; Thu, 12 Jun 2003 15:16:16 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QXDT-0006dF-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 12 Jun 2003 13:54:31 -0500
Received: from palrel13.hp.com ([156.153.255.238])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19QXDS-0006d4-00
	for ipfix@net.doit.wisc.edu; Thu, 12 Jun 2003 13:54:30 -0500
Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62])
	by palrel13.hp.com (Postfix) with ESMTP
	id 65E961C009C4; Thu, 12 Jun 2003 11:54:29 -0700 (PDT)
Received: from xpabh1.ptp.hp.com (xpabh1.ptp.hp.com [15.1.28.60])
	by xparelay1.ptp.hp.com (Postfix) with ESMTP
	id 0428F10054CC; Thu, 12 Jun 2003 11:54:29 -0700 (PDT)
Received: by xpabh1.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <MPH33BPZ>; Thu, 12 Jun 2003 11:54:28 -0700
Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960080@xsun01.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Benoit Claise'" <bclaise@cisco.com>, Tal Givoly <givoly@xacct.com>
Cc: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        Mark Fullmer <maf@eng.oar.net>, calato@riverstonenet.com,
        ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] drawing the line between protocol and data model docu
	ment
Date: Thu, 12 Jun 2003 11:54:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C33114.07FAF4E0"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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_01C33114.07FAF4E0
Content-Type: text/plain;
	charset="iso-8859-1"

Benoit,
 
  From a purely practical matter.  What does NFv9 do today?  Are any
counters 64-bit (e.g. length=8) or are they all 32-bit (e.g. length=4).  Do
you anticipate doing things like length=7, length=33?
 
  If you are saying that this kind of "flexibility" is a good thing.  I.e. I
should write a consuming app to accept a template which might have
length="11" vs. knowing that the data model explicitly is sending me values
of some more constrained type (e.g. an integer in the range of 0-2^32), I
disagree.
 
  Again, I don't see a need to change the encoding, continue sending length.
But for items defined in the information model, be EXPLICIT about their
capacity.  Don't just say "its numeric".  
 
  If we need 128-bit counters later, fine, we can extend the information
model, and give specific names to these items and the protocol will continue
to work w/o change.
 
Regards,
 
  Jeff Meyer
 
 -----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Thursday, June 12, 2003 5:47 AM
To: Tal Givoly
Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); Mark Fullmer;
calato@riverstonenet.com; ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] drawing the line between protocol and data model
document



Tal, Jeff,

[let me reply to both of you in a single email]


Benoit,
 
I agree with Jeff. I would add that, no more than 2 options should be
available for bytes/packet counters (32/64-bit unsigned integers).
 
But I would consider offering only a 64-bit value for byte counters. From
SNMP we learned that 32-bit byte counters cause countless problems. Since
IPFIX byte counters may be a result of aggregates, with today's networks it
is very feasible to overflow the 32-bit integer container.

How often do you poll the SNMP variables like interface counters? 5 minutes?
This is order of magnitude higher than the flow expiration, in most of the
cases.

http://www.ietf.org/internet-drafts/draft-claise-netflow-9-02.txt
<http://www.ietf.org/internet-drafts/draft-claise-netflow-9-02.txt> 
    -> 3.2 Flow Expiration

   A Flow is considered to be inactive if no packets belonging to the 

   Flow have been observed at the Observation Point for a given timeout 

   interval otherwise it is considered as an active flow.  

   A Flow can be exported under the following conditions: 

    

      1. If the Exporter can detect the end of a Flow, it SHOULD export 

      the Flow Records at the end of the Flow. For example, a Flow 

      generated by TCP [3] 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, with a minimum 

      value of 0 for an immediate expiration. For example, a Flow 

      generated by UDP [2] type of traffic. 

       

      3. For long-lasting Flows, the Exporter SHOULD export the Flow 

      Records on a regular basis. This periodicity SHOULD be 

      configurable. 

       

      4. If the Exporter experiences internal constraints, a Flow MAY 

      be forced to expire prematurely (for example, counters wrapping 

      or low memory). 



So it's only in case 3 (so potentially an aggregation, as you described)
that we could potentially needs a higher counter.

And in that case again, a simple solution is to export the flow records just
before it reaches the max value of counter32 (in case the length for
counter32 is choosen).



But if you don't want that, there is also another solution: when this case
3. occurs, you can define a new template with the length corresponding to
counter64.

And then you have 2 templates: one with counter32 (used most of the time)
and one with counter64 (used in a few cases).



Another solution, nothing prevents you to export flow data records always
with counter64



See below...

 
Tal

-----Original Message-----
From: majordomo listserver [ mailto:majordomo@mil.doit.wisc.edu
<mailto:majordomo@mil.doit.wisc.edu> ]On Behalf Of MEYER,JEFFREY D
(HP-Cupertino,ex1)
Sent: Wednesday, June 11, 2003 10:00 AM
To: 'Benoit Claise'
Cc: Mark Fullmer; calato@riverstonenet.com <mailto:calato@riverstonenet.com>
; ipfix@net.doit.wisc.edu <mailto:ipfix@net.doit.wisc.edu> 
Subject: RE: [ipfix] drawing the line between protocol and data model
document


Hi,
 
  >From a practical perspective, simply saying that a field is numeric and
may be encoded as 1 or 100 bytes seems like it puts an unnecessary and
unjustified burden on the collector, or any other app which might want to
handle this data.

Am I correct that the burden would only be when you decode the template
records?
Because when you receive a Data FlowSet, the collecting process must read
the FlowSet ID and automatically know the data type length.


 
  Is there some particular reason why saying a specific information item,
e.g. numBytes, is a 32-bit integer or a 64-bit integer is considered
undesireable. 


But then, why to limit to 32-bit and 64-bit integer? What about other
possibilities? Where to stop? Then we end up with a long information model
because this principle of 32-bit, 64-bit integer should be then applied to
all data type that are counters.


It certainly seems like the developer of a consuming application would
benefit from knowing how to target variables in their application for given
information items.  I guess one could assume that everything will fit in a
64-bit integer and code your app that way, but again, this seems like an
unnecessary burden for unclear gains.

The gain, as I see it, is in the flexibility with a simple information model

Regards, Benoit.



 
  I don't think anything needs to change in the protocol.  Simply a more
constrained approach to dealing with numeric fields with explicit types.
 
Regards,

  Jeff Meyer

-----Original Message-----
From: Benoit Claise [ mailto:bclaise@cisco.com <mailto:bclaise@cisco.com> ]
Sent: Wednesday, June 11, 2003 4:31 AM
To: Benoit Claise
Cc: Mark Fullmer; calato@riverstonenet.com <mailto:calato@riverstonenet.com>
; ipfix@net.doit.wisc.edu <mailto:ipfix@net.doit.wisc.edu> 
Subject: Re: [ipfix] drawing the line between protocol and data model
document


Dear all,


Mark, 

On Thu, May 01, 2003 at 10:51:49AM -0400,  calato@riverstonenet.com
<mailto:calato@riverstonenet.com>  wrote:



<snip>



  

The richness of the protocol encoding specification is another

matter. The protocol would reference each element in the data

model and define exaclty how that element is encoded. In the above 

example, the protocol is free to encode that as an unsigned byte 

if the value is < 256. 

    



The ramifications of doing this with a template based system are a bit

ugly.  Consider a flow with just 2 counters -- octets, packets.

Each could have a 1 to 8 byte encoding.  That's a potential of 64

different templates for representing 1 type of flow.



This (at first glance) looks like it adds considerable cycles to the

encode / decode process to save a few bytes in the transport.



The current v9 spec appears to allow this, but only for IN_BYTES and

IN_PKTS.



  

                                          counter with length

   IN_BYTES                 1       N     N x 8 bits for bytes

                                          associated with an IP Flow

    



Is this true?  Benoit?

  

I'm trying to catch up with my IPIFX emails; I know I'm late on this thread,
which seems to have reached consensus as far as I can tell, but as this is a
direct question to me, let me answer.
Actually, there are:
BYTES            1             4             field type for the 32 bit bytes
counter
BYTES_64      23           8             field type for the 64 bit bytes
counter

Let me reply to my own email because, after speaking to different people, I
have to correct what I said.
We actually do:

                                          Incoming counter with length

   IN_BYTES                 1       N     N x 8 bits for bytes

                                          associated with an IP Flow



                                          Incoming counter with length

   IN_PKTS		    2       N     N x 8 bits for packets

                                          associated with an IP Flow



And no BYTES_64 is defined.



Regards, Benoit.







So the draft that you refer to needs a quick update.
<!--[endif]-->
Regards, Benoit





mark



--

Help         mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say "help " in message body
<inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay> 

Unsubscribe mailto:majordomo@net.doit.wisc.edu and say

"unsubscribe ipfix" in message body

Archive      http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/> 

  





------_=_NextPart_001_01C33114.07FAF4E0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE></TITLE>

<META content="MSHTML 5.50.4915.500" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=656495218-12062003><FONT face=Arial color=#0000ff 
size=2>Benoit,</FONT></SPAN></DIV>
<DIV><SPAN class=656495218-12062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=656495218-12062003><FONT face=Arial color=#0000ff size=2>&nbsp; 
From a purely practical matter.&nbsp; What does NFv9 do today?&nbsp; Are any 
counters 64-bit (e.g. length=8) or are they all 32-bit (e.g. length=4).&nbsp; Do 
you anticipate doing things like length=7, length=33?</FONT></SPAN></DIV>
<DIV><SPAN class=656495218-12062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=656495218-12062003><FONT face=Arial color=#0000ff size=2>&nbsp; 
If you are saying that this kind of "flexibility" is a good thing.&nbsp; I.e. I 
should write a consuming app to accept a template which might have length="11" 
vs. knowing that the data model explicitly is sending me values of some more 
constrained type (e.g. an integer in the range of 0-2^32), I 
disagree.</FONT></SPAN></DIV>
<DIV><SPAN class=656495218-12062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=656495218-12062003><FONT face=Arial color=#0000ff size=2>&nbsp; 
Again, I don't see a need to change the encoding, continue sending length.&nbsp; 
But for items defined in the information model, be EXPLICIT about their 
capacity.&nbsp; Don't just say "its numeric".&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=656495218-12062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=656495218-12062003><FONT face=Arial color=#0000ff size=2>&nbsp; 
If we need 128-bit counters later, fine, we can extend the information model, 
and give specific names to these items and the protocol will continue to work 
w/o change.</FONT></SPAN></DIV>
<DIV><SPAN class=656495218-12062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=656495218-12062003><FONT face=Arial color=#0000ff 
size=2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=656495218-12062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=656495218-12062003><FONT face=Arial color=#0000ff size=2>&nbsp; 
Jeff Meyer</FONT></SPAN></DIV>
<DIV><SPAN class=656495218-12062003></SPAN><FONT face=Tahoma><FONT size=2><SPAN 
class=656495218-12062003><FONT face=Arial 
color=#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=656495218-12062003>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
Benoit Claise [mailto:bclaise@cisco.com]<BR><B>Sent:</B> Thursday, June 12, 2003 
5:47 AM<BR><B>To:</B> Tal Givoly<BR><B>Cc:</B> MEYER,JEFFREY D 
(HP-Cupertino,ex1); Mark Fullmer; calato@riverstonenet.com; 
ipfix@net.doit.wisc.edu<BR><B>Subject:</B> Re: [ipfix] drawing the line between 
protocol and data model document<BR><BR></DIV></FONT></FONT>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">Tal, 
  Jeff,<BR><BR>[let me reply to both of you in a single email]<BR>
  <BLOCKQUOTE cite="midDLEIIIOHMNPJPNMKGEFDEEGIDKAA.givoly@xacct.com" 
  type="cite">
    <META content="MSHTML 6.00.2722.900" name=GENERATOR>
    <DIV><SPAN class=768200504-12062003><FONT face=Arial color=#0000ff 
    size=2>Benoit,</FONT></SPAN></DIV>
    <DIV><SPAN class=768200504-12062003></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=768200504-12062003><FONT face=Arial><FONT 
    color=#0000ff><FONT size=2>I agree with Jeff. I would add that<SPAN 
    class=768200504-12062003>, no more than&nbsp;2 options should be available 
    for bytes/packet counters (32/64-bit unsigned 
    integers).</SPAN></FONT></FONT></FONT></SPAN></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=Arial color=#0000ff size=2>But I would consider 
    offering&nbsp;<SPAN class=768200504-12062003><STRONG>only</STRONG> </SPAN>a 
    64-bit value for byte counters. From SNMP we learned that 32-bit byte 
    counters cause countless problems. Since IPFIX byte counters may be a result 
    of aggregates, with today's networks it is very feasible to overflow the 
    32-bit integer container.</FONT></DIV></BLOCKQUOTE>How often do you poll the 
  SNMP variables like interface counters? 5 minutes?<BR>This is order of 
  magnitude higher than the flow expiration, in most of the cases.<BR><BR><A 
  class=moz-txt-link-freetext 
  href="http://www.ietf.org/internet-drafts/draft-claise-netflow-9-02.txt">http://www.ietf.org/internet-drafts/draft-claise-netflow-9-02.txt</A><BR>&nbsp;&nbsp;&nbsp; 
  -&gt; 3.2 Flow Expiration<BR><PRE>   A Flow is considered to be inactive if no packets belonging to the 
   Flow have been observed at the Observation Point for a given timeout 
   interval otherwise it is considered as an active flow.  
   A Flow can be exported under the following conditions: 
    
      1. If the Exporter can detect the end of a Flow, it SHOULD export 
      the Flow Records at the end of the Flow. For example, a Flow 
      generated by TCP [3] 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, with a minimum 
      value of 0 for an immediate expiration. For example, a Flow 
      generated by UDP [2] type of traffic. 
       
      3. For long-lasting Flows, the Exporter SHOULD export the Flow 
      Records on a regular basis. This periodicity SHOULD be 
      configurable. 
       
      4. If the Exporter experiences internal constraints, a Flow MAY 
      be forced to expire prematurely (for example, counters wrapping 
      or low memory). 

So it's only in case 3 (so potentially an aggregation, as you described) that we could potentially needs a higher counter.
And in that case again, a simple solution is to export the flow records just before it reaches the max value of counter32 (in case the length for counter32 is choosen).

But if you don't want that, there is also another solution: when this case 3. occurs, you can define a new template with the length corresponding to counter64.
And then you have 2 templates: one with counter32 (used most of the time) and one with counter64 (used in a few cases).

Another solution, nothing prevents you to export flow data records always with counter64

See below...
</PRE>
  <BLOCKQUOTE cite="midDLEIIIOHMNPJPNMKGEFDEEGIDKAA.givoly@xacct.com" 
  type="cite">
    <DIV><SPAN class=768200504-12062003></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=768200504-12062003><FONT face=Arial color=#0000ff 
    size=2>Tal</FONT></SPAN></DIV>
    <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> majordomo listserver [<A 
      class=moz-txt-link-freetext 
      href="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</A>]<B>On 
      Behalf Of </B>MEYER,JEFFREY D (HP-Cupertino,ex1)<BR><B>Sent:</B> 
      Wednesday, June 11, 2003 10:00 AM<BR><B>To:</B> 'Benoit 
      Claise'<BR><B>Cc:</B> Mark Fullmer; <A class=moz-txt-link-abbreviated 
      href="mailto:calato@riverstonenet.com">calato@riverstonenet.com</A>; <A 
      class=moz-txt-link-abbreviated 
      href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</A><BR><B>Subject:</B> 
      RE: [ipfix] drawing the line between protocol and data model 
      document<BR><BR></FONT></DIV>
      <DIV><SPAN class=718225916-11062003><FONT face=Arial color=#0000ff 
      size=2>Hi,</FONT></SPAN></DIV>
      <DIV><SPAN class=718225916-11062003></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=718225916-11062003><FONT face=Arial color=#0000ff 
      size=2>&nbsp; &gt;From a practical perspective, simply saying that a field 
      is numeric and may be encoded as 1 or 100 bytes seems like it puts an 
      unnecessary and unjustified burden on the collector, or any other app 
      which might want to handle this 
  data.</FONT></SPAN></DIV></BLOCKQUOTE></BLOCKQUOTE>Am I correct that the 
  burden would only be when you decode the template records?<BR>Because when you 
  receive a Data FlowSet, the collecting process must read the FlowSet ID and 
  automatically know the data type length.<BR>
  <BLOCKQUOTE cite="midDLEIIIOHMNPJPNMKGEFDEEGIDKAA.givoly@xacct.com" 
  type="cite">
    <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
      <DIV><SPAN class=718225916-11062003></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=718225916-11062003><FONT face=Arial color=#0000ff 
      size=2>&nbsp; Is there some particular reason why saying a specific 
      information item, e.g. numBytes, is a 32-bit integer or a 64-bit integer 
      is considered undesireable. 
  <BR></FONT></SPAN></DIV></BLOCKQUOTE></BLOCKQUOTE>But then, why to limit to 
  32-bit and 64-bit integer? What about other possibilities? Where to stop? Then 
  we end up with a long information model because this principle of 32-bit, 
  64-bit integer should be then applied to all data type that are counters.<BR>
  <BLOCKQUOTE cite="midDLEIIIOHMNPJPNMKGEFDEEGIDKAA.givoly@xacct.com" 
  type="cite">
    <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
      <DIV><SPAN class=718225916-11062003><FONT face=Arial color=#0000ff 
      size=2>It certainly seems like the developer of a consuming application 
      would benefit from knowing how to target variables in their application 
      for given information items.&nbsp; I guess one could assume that 
      everything will fit in a 64-bit integer and code your app that way, but 
      again, this seems like an unnecessary burden for unclear 
      gains.</FONT></SPAN></DIV></BLOCKQUOTE></BLOCKQUOTE>The gain, as I see it, is 
  in the flexibility with a simple information model<BR><BR>Regards, 
  Benoit.<BR><BR>
  <BLOCKQUOTE cite="midDLEIIIOHMNPJPNMKGEFDEEGIDKAA.givoly@xacct.com" 
  type="cite">
    <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
      <DIV><SPAN class=718225916-11062003></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=718225916-11062003><FONT face=Arial color=#0000ff 
      size=2>&nbsp; I don't think anything needs to change in the 
      protocol.&nbsp; Simply a more constrained approach to dealing with numeric 
      fields with explicit types.</FONT></SPAN></DIV>
      <DIV><SPAN class=718225916-11062003></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=718225916-11062003><FONT face=Arial color=#0000ff 
      size=2>Regards,</FONT></SPAN></DIV>
      <DIV><SPAN class=718225916-11062003><FONT face=Arial color=#0000ff 
      size=2><BR>&nbsp; Jeff Meyer</FONT></SPAN></DIV>
      <BLOCKQUOTE 
      style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(0,0,255) 2px solid">
        <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
        size=2>-----Original Message-----<BR><B>From:</B> Benoit Claise [<A 
        class=moz-txt-link-freetext 
        href="mailto:bclaise@cisco.com">mailto:bclaise@cisco.com</A>]<BR><B>Sent:</B> 
        Wednesday, June 11, 2003 4:31 AM<BR><B>To:</B> Benoit 
        Claise<BR><B>Cc:</B> Mark Fullmer; <A class=moz-txt-link-abbreviated 
        href="mailto:calato@riverstonenet.com">calato@riverstonenet.com</A>; <A 
        class=moz-txt-link-abbreviated 
        href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</A><BR><B>Subject:</B> 
        Re: [ipfix] drawing the line between protocol and data model 
        document<BR><BR></FONT></DIV>Dear all,<BR>
        <BLOCKQUOTE cite="mid3EDCB48D.40207@cisco.com" type="cite">Mark, 
          <BLOCKQUOTE cite="mid20030501162116.B33173@net.ohio-state.edu" 
          type="cite"><PRE wrap="">On Thu, May 01, 2003 at 10:51:49AM -0400, <A class=moz-txt-link-abbreviated href="mailto:calato@riverstonenet.com">calato@riverstonenet.com</A> wrote:

&lt;snip&gt;

  </PRE>
            <BLOCKQUOTE type="cite"><PRE wrap="">The richness of the protocol encoding specification is another
matter. The protocol would reference each element in the data
model and define exaclty how that element is encoded. In the above 
example, the protocol is free to encode that as an unsigned byte 
if the value is &lt; 256. 
    </PRE></BLOCKQUOTE><PRE wrap=""><!---->
The ramifications of doing this with a template based system are a bit
ugly.  Consider a flow with just 2 counters -- octets, packets.
Each could have a 1 to 8 byte encoding.  That's a potential of 64
different templates for representing 1 type of flow.

This (at first glance) looks like it adds considerable cycles to the
encode / decode process to save a few bytes in the transport.

The current v9 spec appears to allow this, but only for IN_BYTES and
IN_PKTS.

  </PRE>
            <BLOCKQUOTE type="cite"><PRE wrap="">                                          counter with length
   IN_BYTES                 1       N     N x 8 bits for bytes
                                          associated with an IP Flow
    </PRE></BLOCKQUOTE><PRE wrap=""><!---->
Is this true?  Benoit?
  </PRE></BLOCKQUOTE>I'm trying to catch up with my IPIFX emails; I 
          know I'm late on this thread, which seems to have reached consensus as 
          far as I can tell, but as this is a direct question to me, let me 
          answer.<BR>Actually, there are:<BR>BYTES&nbsp; &nbsp;&nbsp; 
          &nbsp;&nbsp; &nbsp; &nbsp; 1 &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; 
          &nbsp;&nbsp; 4 &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; 
          field type for the 32 bit bytes counter<BR>BYTES_64&nbsp;&nbsp; 
          &nbsp;&nbsp; 23&nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; 
          8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          field type for the 64 bit bytes counter</BLOCKQUOTE>Let me reply to my 
        own email because, after speaking to different people, I have to correct 
        what I said.<BR>We actually do:<BR><PRE wrap="">                                          Incoming counter with length
   IN_BYTES                 1       N     N x 8 bits for bytes
                                          associated with an IP Flow

                                          Incoming counter with length
   IN_PKTS		    2       N     N x 8 bits for packets
                                          associated with an IP Flow

And no BYTES_64 is defined.

Regards, Benoit.

<SPAN lang=EN-US style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'"><SPAN></SPAN><SPAN></SPAN></SPAN></PRE>
        <BLOCKQUOTE cite="mid3EDCB48D.40207@cisco.com" type="cite"><BR><BR>So 
          the draft that you refer to needs a quick 
          update.<BR>&lt;!--[endif]--&gt;<O:IDMAP data="3" 
          v:ext="edit"></O:IDMAP><BR>Regards, Benoit<BR><BR><BR><BR>
          <BLOCKQUOTE cite="mid20030501162116.B33173@net.ohio-state.edu" 
          type="cite"><PRE wrap="">mark

--
Help        <A class=moz-txt-link-freetext href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</A> and say "help<A class=moz-txt-link-rfc2396E href="inmessagebodyUnsubscribemailto:majordomo@net.doit.wisc.eduandsay">" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"</A>unsubscribe ipfix" in message body
Archive     <A class=moz-txt-link-freetext href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</A>
  </PRE></BLOCKQUOTE><BR></BLOCKQUOTE><BR></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C33114.07FAF4E0--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 12 19:10:41 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00967
	for <ipfix-archive@lists.ietf.org>; Thu, 12 Jun 2003 19:10:40 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Qan7-0004pV-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 12 Jun 2003 17:43:33 -0500
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Qan6-0004pP-00
	for ipfix@net.doit.wisc.edu; Thu, 12 Jun 2003 17:43:32 -0500
Received: from Givoly (000-017-881.area1.spcsdns.net [68.24.70.102])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h5CMnNW05998;
	Thu, 12 Jun 2003 15:49:40 -0700
From: "Tal Givoly" <givoly@xacct.com>
To: "Ganesh Sadasivan" <gsadasiv@cisco.com>
Cc: <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] IPFIX-ARCH : Functional flow diagram.
Date: Thu, 12 Jun 2003 15:41:50 -0700
Message-ID: <DLEIIIOHMNPJPNMKGEFDOEHCDKAA.givoly@xacct.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01F4_01C330F9.23D027A0"
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 V6.00.2600.0000
Importance: Normal
In-Reply-To: <3EE88C18.99B1383D@cisco.com>
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.

------=_NextPart_000_01F4_01C330F9.23D027A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I probably wasn't clear enough... that happens.
   What did you mean by aggregation? Is it of flows ?
Yes, aggregation of flows based on some policy.

   Anonymization IMO is a protocol function and we need to add this to the
rule and
   function.

I cannot see how anonymization is part of the protocol (or the Export
Process). The EP should be abstracted from this level of detail, as it
should from aggregation, sampling, etc.

Are the rest of the points I made clearer?

Tal

  -----Original Message-----
  From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
  Sent: Thursday, June 12, 2003 7:20 AM
  To: Tal Givoly
  Cc: ipfix@net.doit.wisc.edu
  Subject: Re: [ipfix] IPFIX-ARCH : Functional flow diagram.


  Tal,
     I agree with you that the diagram does not show the complete
interconnects.
     Sorry, I did not mention that this diagram is in addition to the
already existing
     diagram in the arch spec that shows the interconnects which needs some
     modification.
     I was planning to just put the important functions in the diagram and
the detail
     text for each module would  in the different sections. But then maybe
we need
     to still modify the text in the blocks.
     What did you mean by aggregation? Is it of flows ? There is text in
"flow recording
     process" which mentions about aggregate statistics. But that has
nothing to do with
     aggregation itself.
     Anonymization IMO is a protocol function and we need to add this to the
rule and
     function.

  Thanks
  Ganesh


  Tal Givoly wrote:

     Ganesh,Usually, diagrams are useful for illustration of concepts, but
aren't ideal for specification. If you would like this to be a specification
of the inner workings of the metering process and exporting process, I would
recommend you add the following:- Identification of all modules and
interconnects- Text that describes each of these modules and interconnects
to disambiguate it for the reader.Regarding the content itself - I believe
aggregation is not clear. Also annonymization location isn't clear.It seems
to me to make more sense to have two distinct diagrams - one at the high
level showing MP (many to 1) -> EP. Then it would be possible to blow up the
MP and the EP independently and discuss them independently. The EP depends
primarily on the protocol features while the MP would have the support for
most of the capabilities such as timestamping, and others that you
discuss.Tal-----Original Message-----
    From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Ganesh Sadasivan
    Sent: Wednesday, June 11, 2003 11:58 AM
    To: ipfix@net.doit.wisc.edu
    Subject: [ipfix] IPFIX-ARCH : Functional flow diagram.

      Hi,
         I want to add this figure into the architecture spec. Please go
through this send
         send any comments/corrections.
                          Packet(s) coming into Observation Point(s)
                          |                                   |
                          |                                   |
                          v                                   v
        +-----------------+-------------------------+   +-----+------+
        |           Metering Process on an          |   |            |
        |              Observation Point            |   |            |
        |  packet header capturing                  |   |            |
        |         |                                 |   | Metering   |
        |    timestamping                           |   | Process    |
        |         |                                 |   | on an      |
        |         v                                 |   | Observation|
        |  +------+                                 |   | Point      |
        |  |      |                                 |   |            |
        |  |   sampling Si (1:1 in case of no       |   |            |
        |  |      |          sampling)              |   |            |
        |  | classifying Fi (NULL when No criteria) |   |            |
        |  |      |                                 |   |            |
        |  +------+                                 |   |            |
        |         |                                 |   |            |
        +---------+---------------------------------+   +-----+------+
                  |                                           |
                Flows (identified by observation domain)    Flows
                  +----...                                    +--------+...
                  |                                           v
                  |
+-------------------------------------+----------------+
                  |     |             Flow Recording Process(*)
|
                  |     | +----------------------+     +------------------+
|
                  |     | | Flow data base       |<----|Provide non-flow  |
|
                  |     | | (includes flows      |     | information (Eg. |
|
                  |     | | from all obs.        |     | router state)    |
|
                  |     | | points in an obs.    |     +------------------+
|.....
                  |     | | domain)              |
|
                  |     | |                      |     +------------------+
|
                  |     | |                      |<----|Maintain aggregate|
|
                  |     | |                      |     | statistics       |
|
                  |     | +----------------------+     +------------------+
|
                  |
+-------------------------------+----------------------+
                  |                                     |
                  |        Flow Database (identified by observation domain)
                  |
+------------------------....
                  v                                     v

+-----------+-------------------------------------+-------------------------
-+
      |           |            Export Process           |
|
      |           |
+----------------------... |
      |
+---------+------------------------------------------------------------+   |
      | |         v                  IPFIX Protocol
|   |
      | |+---------------------------------+
+-------------------------------+|   |
      | || Rules for                       |  |Functions
||   |
      | || - Picking & sending templates   |  |- Packetize selected control
||   |
      | || - Picking & sending data records|->|  & data information into
||   |
      | || - Timing out flows              |  |  IPFIX export packet.
||...|
      | || - Encoding template & data      |  |- Handle export errors
||   |
      | || - Selecting flows for export(*) |  |- Handle timeouts & overloads
||   |
      | |+---------------------------------+
+-------------------------------+|   |
      | |
|   |
      |
+-----------------------------+----------------------------------------+   |
      |                               |
|
      |
+-----------------------------------------...|
      |                     IPFIX exported packet
|
      |                               |
|
      |
+-----------------------------+----------------------------------------+   |
      | |                        Transport  Protocol
|   |
      |
+-----------------------------+----------------------------------------+   |
      |                               |
|

+-------------------------------+-------------------------------------------
-+
                                      |
                                      v
                              IPFIX export packet to collector.

      (*) indicates that the block is optional.

      Thanks
      Ganesh




------=_NextPart_000_01F4_01C330F9.23D027A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2722.900" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D486263422-12062003><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
probably wasn't clear enough... that happens.</FONT></SPAN></DIV>
<DIV><SPAN class=3D486263422-12062003>&nbsp;&nbsp; What did you mean by=20
aggregation? </SPAN><SPAN class=3D486263422-12062003>Is it of flows ?=20
</SPAN></DIV>
<DIV><SPAN class=3D486263422-12062003><FONT face=3DArial color=3D#0000ff =
size=3D2>Yes,=20
aggregation of flows based on some policy.</FONT></SPAN></DIV>
<DIV><SPAN class=3D486263422-12062003><BR>&nbsp;&nbsp; Anonymization IMO =
is a=20
protocol function and we need to add this to the rule and =
<BR>&nbsp;&nbsp;=20
function. </DIV>
<DIV><SPAN class=3D486263422-12062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D486263422-12062003><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
cannot see how anonymization is part of the protocol (or the Export =
Process).=20
The EP should be abstracted from this level of detail, as it should from =

aggregation, sampling, etc.</FONT></SPAN></DIV>
<DIV><SPAN class=3D486263422-12062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D486263422-12062003><FONT face=3DArial color=3D#0000ff =
size=3D2>Are=20
the rest of the points I made clearer?</FONT></SPAN></DIV>
<DIV><SPAN class=3D486263422-12062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D486263422-12062003><FONT face=3DArial color=3D#0000ff =

size=3D2>Tal</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial color=3D#0000ff=20
size=3D2></FONT></SPAN><SPAN =
class=3D486263422-12062003></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Ganesh Sadasivan=20
  [mailto:gsadasiv@cisco.com]<BR><B>Sent:</B> Thursday, June 12, 2003 =
7:20=20
  AM<BR><B>To:</B> Tal Givoly<BR><B>Cc:</B>=20
  ipfix@net.doit.wisc.edu<BR><B>Subject:</B> Re: [ipfix] IPFIX-ARCH : =
Functional=20
  flow diagram.<BR><BR></FONT></DIV>Tal,=20
  <P>&nbsp;&nbsp; I agree with you that the diagram does not show the =
complete=20
  interconnects. <BR>&nbsp;&nbsp; Sorry, I did not mention that this =
diagram is=20
  in addition to the already existing <BR>&nbsp;&nbsp; diagram in the =
arch spec=20
  that shows the interconnects which needs some <BR>&nbsp;&nbsp; =
modification.=20
  <BR>&nbsp;&nbsp; I was planning to just put the important functions in =
the=20
  diagram and the detail <BR>&nbsp;&nbsp; text for each module =
would&nbsp; in=20
  the different sections. But then maybe we need <BR>&nbsp;&nbsp; to =
still=20
  modify the text in the blocks. <BR>&nbsp;&nbsp; What did you mean by=20
  aggregation? Is it of flows ? There is text in "flow recording=20
  <BR>&nbsp;&nbsp; process" which mentions about aggregate statistics. =
But that=20
  has nothing to do with <BR>&nbsp;&nbsp; aggregation itself. =
<BR>&nbsp;&nbsp;=20
  Anonymization IMO is a protocol function and we need to add this to =
the rule=20
  and <BR>&nbsp;&nbsp; function.=20
  <P>Thanks <BR>Ganesh=20
  <P> <BR>Tal Givoly wrote:=20
  <BLOCKQUOTE TYPE=3D"CITE">&nbsp;<SPAN class=3D796145803-12062003><FONT =

    face=3DArial><FONT color=3D#0000ff><FONT=20
    size=3D-1>Ganesh,</FONT></FONT></FONT></SPAN><SPAN=20
    class=3D796145803-12062003></SPAN><SPAN =
class=3D796145803-12062003><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D-1>Usually, diagrams =
are useful=20
    for illustration of concepts, but aren't ideal for specification. If =
you=20
    would like this to be a specification of the inner workings of the =
metering=20
    process and exporting process, I would recommend you add the=20
    following:</FONT></FONT></FONT></SPAN><SPAN =
class=3D796145803-12062003><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D-1>- Identification =
of all modules=20
    and interconnects</FONT></FONT></FONT></SPAN><SPAN=20
    class=3D796145803-12062003><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
    size=3D-1>- Text that describes each of these modules and =
interconnects to=20
    disambiguate it for the reader.</FONT></FONT></FONT></SPAN><SPAN=20
    class=3D796145803-12062003></SPAN><SPAN =
class=3D796145803-12062003><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D-1>Regarding the =
content itself -=20
    I believe aggregation is not clear. Also annonymization location =
isn't=20
    clear.</FONT></FONT></FONT></SPAN><SPAN=20
    class=3D796145803-12062003></SPAN><SPAN =
class=3D796145803-12062003><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D-1>It seems to me to =
make more=20
    sense to have two distinct diagrams - one at the high level showing =
MP (many=20
    to 1) -&gt; EP. Then it would be possible to blow up the MP and the =
EP=20
    independently and discuss them independently. The EP depends =
primarily on=20
    the protocol features while the MP would have the support for most =
of the=20
    capabilities such as timestamping, and others that you=20
    discuss.</FONT></FONT></FONT></SPAN><SPAN=20
    class=3D796145803-12062003></SPAN><SPAN =
class=3D796145803-12062003><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT=20
    size=3D-1>Tal</FONT></FONT></FONT></SPAN><SPAN=20
    class=3D796145803-12062003></SPAN><FONT face=3DTahoma><FONT=20
    size=3D-1>-----Original Message-----</FONT></FONT> <BR><FONT =
face=3DTahoma><FONT=20
    size=3D-1><B>From:</B> majordomo listserver [<A=20
    =
href=3D"mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wis=
c.edu</A>]<B>On=20
    Behalf Of </B>Ganesh Sadasivan</FONT></FONT> <BR><FONT =
face=3DTahoma><FONT=20
    size=3D-1><B>Sent:</B> Wednesday, June 11, 2003 11:58 =
AM</FONT></FONT>=20
    <BR><FONT face=3DTahoma><FONT size=3D-1><B>To:</B>=20
    ipfix@net.doit.wisc.edu</FONT></FONT> <BR><FONT face=3DTahoma><FONT=20
    size=3D-1><B>Subject:</B> [ipfix] IPFIX-ARCH : Functional flow=20
    diagram.</FONT></FONT> <BR>&nbsp;=20
    <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"><TT>Hi,</TT>=20
      <BR><TT>&nbsp;&nbsp; I want to add this figure into the =
architecture spec.=20
      Please go through this send</TT> <BR><TT>&nbsp;&nbsp; send any=20
      comments/corrections.</TT>=20
      =
<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      Packet(s) coming into Observation Point(s)</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      v</TT> <BR><TT>&nbsp;=20
      +-----------------+-------------------------+&nbsp;&nbsp;=20
      +-----+------+</TT> <BR><TT>&nbsp;=20
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Metering=20
      Process on =
an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
      <BR><TT>&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
      Observation=20
      =
Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
      <BR><TT>&nbsp; |&nbsp; packet header=20
      =
capturing&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
      <BR><TT>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp; | Metering&nbsp;&nbsp; |</TT> <BR><TT>&nbsp;=20
      |&nbsp;&nbsp;&nbsp;=20
      =
timestamping&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp; | Process&nbsp;&nbsp;&nbsp; |</TT> <BR><TT>&nbsp;=20
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp; | on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> =
<BR><TT>&nbsp;=20
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp; | Observation|</TT> <BR><TT>&nbsp; |&nbsp;=20
      =
+------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp; | Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> =
<BR><TT>&nbsp;=20
      |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
      <BR><TT>&nbsp; |&nbsp; |&nbsp;&nbsp; sampling Si (1:1 in case of=20
      no&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
      <BR><TT>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
sampling)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
      <BR><TT>&nbsp; |&nbsp; | classifying Fi (NULL when No criteria)=20
      |&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
      <BR><TT>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
      <BR><TT>&nbsp; |&nbsp;=20
      =
+------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
      <BR><TT>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</TT>=20
      <BR><TT>&nbsp; =
+---------+---------------------------------+&nbsp;&nbsp;=20
      +-----+------+</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |</TT> =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      Flows (identified by observation domain)&nbsp;&nbsp;&nbsp; =
Flows</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      =
+----...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

      +--------+...</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      v</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      |&nbsp;&nbsp;&nbsp;&nbsp;=20
      +-------------------------------------+----------------+</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      |&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
      Flow Recording=20
      =
Process(*)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      |&nbsp;&nbsp;&nbsp;&nbsp; |=20
      +----------------------+&nbsp;&nbsp;&nbsp;&nbsp;=20
      +------------------+&nbsp;&nbsp;&nbsp; |</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      |&nbsp;&nbsp;&nbsp;&nbsp; | | Flow data=20
      base&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&lt;----|Provide =
non-flow&nbsp;=20
      |&nbsp;&nbsp;&nbsp; |</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      |&nbsp;&nbsp;&nbsp;&nbsp; | | (includes=20
      flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |=20
      information (Eg. |&nbsp;&nbsp;&nbsp; |</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      |&nbsp;&nbsp;&nbsp;&nbsp; | | from all=20
      obs.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp; |=20
      router state)&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; |</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      |&nbsp;&nbsp;&nbsp;&nbsp; | | points in an obs.&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;&nbsp;&nbsp; +------------------+&nbsp;&nbsp;&nbsp;=20
      |.....</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      |&nbsp;&nbsp;&nbsp;&nbsp; | |=20
      =
domain)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
      |</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      |&nbsp;&nbsp;&nbsp;&nbsp; |=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;&nbsp;&nbsp; +------------------+&nbsp;&nbsp;&nbsp; =
|</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      |&nbsp;&nbsp;&nbsp;&nbsp; |=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&lt;----|Maintain aggregate|&nbsp;&nbsp;&nbsp; |</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      |&nbsp;&nbsp;&nbsp;&nbsp; |=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;&nbsp;&nbsp; | =
statistics&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp;&nbsp; |</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      |&nbsp;&nbsp;&nbsp;&nbsp; |=20
      +----------------------+&nbsp;&nbsp;&nbsp;&nbsp;=20
      +------------------+&nbsp;&nbsp;&nbsp; |</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      |&nbsp;&nbsp;&nbsp;&nbsp;=20
      +-------------------------------+----------------------+</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flow Database =
(identified by=20
      observation domain)</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      +------------------------....</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
      =
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      v</TT>=20
      =
<BR><TT>+-----------+-------------------------------------+--------------=
------------+</TT>=20
      =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Export=20
      =
Process&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
      |</TT>=20
      =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      +----------------------... |</TT> <BR><TT>|=20
      =
+---------+------------------------------------------------------------+&=
nbsp;&nbsp;=20
      |</TT> <BR><TT>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

      =
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      IPFIX=20
      =
Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp; |</TT> <BR><TT>| =
|+---------------------------------+&nbsp;=20
      +-------------------------------+|&nbsp;&nbsp; |</TT> <BR><TT>| || =
Rules=20
      =
for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;=20
      =
|Functions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      ||&nbsp;&nbsp; |</TT> <BR><TT>| || - Picking &amp; sending=20
      templates&nbsp;&nbsp; |&nbsp; |- Packetize selected =
control&nbsp;&nbsp;=20
      ||&nbsp;&nbsp; |</TT> <BR><TT>| || - Picking &amp; sending data=20
      records|-&gt;|&nbsp; &amp; data information=20
      into&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp; |</TT> <BR><TT>| =
|| -=20
      Timing out=20
      =
flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
      |&nbsp; |&nbsp; IPFIX export=20
      packet.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
||...|</TT>=20
      <BR><TT>| || - Encoding template &amp; =
data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp; |- Handle export=20
      errors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
||&nbsp;&nbsp;=20
      |</TT> <BR><TT>| || - Selecting flows for export(*) |&nbsp; |- =
Handle=20
      timeouts &amp; overloads&nbsp; ||&nbsp;&nbsp; |</TT> <BR><TT>|=20
      |+---------------------------------+&nbsp;=20
      +-------------------------------+|&nbsp;&nbsp; |</TT> <BR><TT>|=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp; |</TT> <BR><TT>|=20
      =
+-----------------------------+----------------------------------------+&=
nbsp;&nbsp;=20
      |</TT>=20
      =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |</TT>=20
      =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      +-----------------------------------------...|</TT>=20
      =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      IPFIX exported=20
      =
packet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |</TT>=20
      =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |</TT> <BR><TT>|=20
      =
+-----------------------------+----------------------------------------+&=
nbsp;&nbsp;=20
      |</TT> <BR><TT>|=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      Transport&nbsp;=20
      =
Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
      |&nbsp;&nbsp; |</TT> <BR><TT>|=20
      =
+-----------------------------+----------------------------------------+&=
nbsp;&nbsp;=20
      |</TT>=20
      =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |</TT>=20
      =
<BR><TT>+-------------------------------+--------------------------------=
------------+</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      |</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      v</TT>=20
      =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
      IPFIX export packet to collector.</TT>=20
      <P><TT>(*) indicates that the block is optional.</TT>=20
      <P><TT>Thanks</TT> <BR><TT>Ganesh</TT> <BR>&nbsp;=20
  <BR>&nbsp;</P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_01F4_01C330F9.23D027A0--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 13 10:45:33 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08464
	for <ipfix-archive@lists.ietf.org>; Fri, 13 Jun 2003 10:45:32 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19QpId-00070o-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 13 Jun 2003 09:13:03 -0500
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19QpIc-00070a-00
	for ipfix@net.doit.wisc.edu; Fri, 13 Jun 2003 09:13:02 -0500
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5DECwVI054777
	for <ipfix@net.doit.wisc.edu>; Fri, 13 Jun 2003 16:12:58 +0200 (CEST)
Received: from [10.1.1.128] (n-quittek.office [10.1.1.128])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id CD0F2AA9E7
	for <ipfix@net.doit.wisc.edu>; Fri, 13 Jun 2003 15:59:28 +0200 (CEST)
Date: Fri, 13 Jun 2003 16:15:13 +0200
From: Juergen Quittek <quittek@ccrle.nec.de>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-10.txt
Message-ID: <6110726.1055520913@[10.1.1.128]>
In-Reply-To: <200306121119.HAA03592@ietf.org>
References:  <200306121119.HAA03592@ietf.org>
X-Mailer: Mulberry/2.1.2 (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 <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Dear all,

below please find the detailed list of all changes applied to the
Internet-Draft compared to version -09.

    Juergen

-- Internet-Drafts@ietf.org wrote on 12 June 2003 07:19 -0400:

> 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-10.txt
> 	Pages		: 31
> 	Date		: 2003-6-11
> 	

=========================
IPFIX Requirements Issues
=========================



========================================================================
1. timestamp resolution reference
========================================================================
Problem Description:
------------------------------------------------------------------------
   5.4.  Timestamps

     The metering process MUST be able to generate timestamps for the
     first and the last observation of a packet of a flow at the
     observation point. The timestamp resolution MUST be at least the one
     of the sysUpTime [RFC1213], which is one centisecond.

I think I'd rather see a reference to RFC3418 instead of RFC1213.
We can do so by RFC-Editor note. May want to check with authors too.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace ref to RFC1213 by ref to RFC3418
========================================================================
Status: solution committed
========================================================================



========================================================================
2. reporting TOS/traffic class octet or reporting DSCP
========================================================================
Problem Description:
------------------------------------------------------------------------
On page 14 I see:

      9. type of service octet (in case of IPv4), traffic class
         octet (in case of IPv6)

Is that not better state as

      9. DSCP, which is set in the type of service octet (in case of IPv4),
         or in the traffic class octet (in case of IPv6)
========================================================================
Suggested solution:
------------------------------------------------------------------------
   According to RFC 2474, the DSCP covers only 6 bit of the type of
   service octet, and in some cases you want to see the entire byte.
   This is be pointed out by a comment added to item 9.:
   "According to RFC 2474 these octets include the DiffServ Code Point
   that has a length of 6 bit."
========================================================================
Status: solution committed
========================================================================



========================================================================
3. location of reference to RFC 2119
========================================================================
Problem Description:
------------------------------------------------------------------------
   I would prefer to see the paragraph referencing RFC 2119 in section 2.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   Move reference to RFC 2119 to section 2
========================================================================
Status: solution committed
========================================================================



========================================================================
4. bad wording in section 6.3.3, last paragraph
========================================================================
Problem Description:
------------------------------------------------------------------------
   Last paragraph in section 6.3.3 needs to be reworded.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace
     "The security threats from which these 3 requirements are deducted
      are explained in the "Security Considerations" (Section 10)."
   by
     "The security requirements have been derived from an analysis of
      potential security threads. The analysis is summarized in
      Section 10."
========================================================================
Status: solution committed
========================================================================



========================================================================
5. describe potential problem of faked DoS attack
========================================================================
Problem Description:
------------------------------------------------------------------------
   In section 10.2, an important point is left unsaid.  If the injection of
IPFIX traffic fool the network provided into thinking that a DOS attack is
underway, the countermeasures employed by the network provider may actually
deny service to real customers.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace the entire section 10.2 Forgery of Flow Records:
     "If flow records are used in accounting and security applications,
      there are potentially strong incentives to forge exported IPFIX flow
      records (for example to save money or prevent the detection of an
      attack). This can be done either by altering flow records on the path
      or by injecting forged flow records that pretend to be originated by
      the original exporting process. In order to make an IPFIX protocol
      resistant against such attacks, authentication and integrity must be
      provided, as specified in section 6.3.3.

      Special caution is required if security applications rely on flow
      measurements. With forged flow records it is possible to trick on
      security applications. It is for instance possible to pretend that a
      DoS attack happens without even launching a real attack."
   by
     "If flow records are used in accounting and/or security applications,
      there are potentially strong incentives to forge exported IPFIX
      flow records (for example to save money or prevent the detection
      of an attack). This can be done either by altering flow records
      on the path or by injecting forged flow records that pretend to
      be originated by the original exporting process.

      Special caution is required if security applications rely on flow
      measurements. With forged flow records it is possible to trick on
      security applications. It is for instance possible to pretend that
      a DoS attack happens without even launching a real attack. If such
      an injection of IPFIX traffic flow records fools the security
      application, pretending that a DoS attack is underway, then the
      countermeasures employed by the security application may actually
      deny useful non-malicious services.

      In order to make an IPFIX protocol resistant against such attacks,
      authentication and integrity must be provided, as specified in
      section 6.3.3."
========================================================================
Status: solution committed
========================================================================



========================================================================
6. location of appendix
========================================================================
Problem Description:
------------------------------------------------------------------------
   The appendix needs to be moved up in the document.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   move appendix above references, copyright, and authors' addresses
========================================================================
Status: solution committed
========================================================================



========================================================================
7. consistency of appendix
========================================================================
Problem Description:
------------------------------------------------------------------------
   The appendix is outdated. Alignment with the text sections and
   coverage of all requirements need to be checked and fixed.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   --- 5.2 Sampling
   Insert note (h): "If sampling is supported, sampling configuration
   changes MUST be indicated to all collecting processes."

   --- 5.3 Overload behavior
   Insert note (i): "If overload behavior is supported and it induces
   changes in the metering process behavior, the overload behavior MUST
   be clearly defined."

   --- Requirement on packet fragmentation state at the meter is
   missing (section 5.8)
   Add "5.8 Packet Fragmentation state O O - - - O"

   --- 6.1 Dropped packet counter:  This requirement appears as a MUST
   in the appendix, but it is a MAY in current section 6.1
   Replace with: "6.1 Dropped packet counter (h,i) O O O O O O"

   --- 6.1 ToS byte and DSCP: they appear as separate requirements in
   the appendix. Besides, Traffic Class (IPv6) is not mentioned.
   Remove line "6.1 ToS Byte M S M O M M" and leave only
   "6.1 DSCP (a) M S M O M M"

   --- 6.1 BGP AS# is given as MUST in the appendix, but it is a
   MAY in current section 6.1
   Replace "6.1 BGP AS# - S M - - M" with the following line:
   "6.1 src/dst/next hop BGP AS # - O O - - O"

   --- For the Information Model, requirements on ICMP type,
   in/out interface and next hop IP address are missing:
   Add "6.1 ICMP type and code (l) S S - S S S"
   Add note: "(l) If protocol type is ICMP"

   Add "6.1 input/output interface (m) S S S S S S"
   Add note: "(m) This requirement does not apply if the observation
   point is located at a probe device"

   Add "6.1 next hop IP address  O O O O - O
   --- For the Data Model the following requirement is missing:
   "6.2 Independency of the transport protocol S S S S S S"

   --- "6.7 Anonymization O O O O O O"
   Add note: "(n) anonymization MUST be clearly indicated to all
   receiving collecting processes"

   --- Remote configuration requirements:
   Replace "7 Config Measurement & Data Export M M M M M M"
   by "7 Secure remote configuration (a) S S S S S S"

   --- Configuration requirements for metering process:
   Add "7.1 Config overload behavior (a) O O O O O O"

   --- Configuration reqs. for exporting process:
   Config Notifications and Config Anonymization should be changed
   to SHOULD (they are listed as MAY)

   Add the following missing reqs:
   "Config collecting processes S S S S S S"
   "Config reporting interval (a) S S S S S S"
========================================================================
Status: solution committed
========================================================================



========================================================================
8. More concrete definition of byte counter
========================================================================
Problem Description:
------------------------------------------------------------------------
This document goes to a lot of trouble to say exactly what is
exported (e.g. what fields, etc), except for two cases:

      8. byte counter
         Which bytes of a packet are counted MUST be defined exactly.

This document is defining what fields are being reported on;
why can't it also define these two things that must also be
defined?  Is it useful to have different ipfix protocols exporting
different measurements?
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace "Which bytes of a packet are counted MUST be defined
   exactly." by "The sum of the total length in bytes of all IP packets
   belonging to the flow. The total length of a packet covers
   IP header and IP payload."
========================================================================
Status: solution committed
========================================================================



========================================================================
9. More concrete definition of multicast replication factor
========================================================================
Problem Description:
------------------------------------------------------------------------
This document goes to a lot of trouble to say exactly what is
exported (e.g. what fields, etc), except for two cases:

     20. multicast replication factor
         the number of outgoing packets originating from a single
         incoming multicast packet. This is a dynamic property of
         multicast flows, that may change over time. For unicast flows
         it has the constant value 1. The computation of the factor MUST
         be clearly defined.

This document is defining what fields are being reported on;
why can't it also define these two things that must also be
defined?  Is it useful to have different ipfix protocols exporting
different measurements?
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace last sentence by "The reported value MUST be the value of the
   factor at the time the flow record is exported."
========================================================================
Status: solution committed
========================================================================



========================================================================
10. More concrete definition of BGP-related attributes
========================================================================
Problem Description:
------------------------------------------------------------------------
Also, at the end of 6.1 it kind of says "Plus other stuff related to inter-AS
routing if you want".  It's already in the MAY section; can't they just
list some concrete items related to inter-AS routing as 27, 28, ...?
I don't think it's useful to say what amounts to "plus anything else that
you might feel like adding that you think is relevant", since that doesn't
encourage different people to make the same choices.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   add three more MAY attributes:
   - 27. source BGP Autonomous System number [RFC1771]
   - 28. destination BGP Autonomous System number
   - 29. next hop BGP Autonomous System number
========================================================================
Status: solution committed
========================================================================



========================================================================
11. Address the reliability issue of usage based accounting
========================================================================
Problem Description:
------------------------------------------------------------------------
The applications include usage-based accounting.  They should cite RFC 2975,
and indicate that the particular niche for usage-based accounting would not
be met if reliability was not very high.  Section 5.1 reliability requirements
do not meet the needs, nor do the timestamping of first and last packet of
a flow, because the flow may have been mischaracterized and that is first and
last of different flows.  The way to satisfy this issue is to caveat the
discussion of usage-based accounting with strong words on reliability that
counter the comments on lesser reliability and more probabilistic techniques
for other applications of ipfix.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   remove from section 3:
     "Please note, that the described applications can have a large number
      of differing implementations. Requirement details or the weighting of
      requirements could differ for specific implementations. Therefore we
      derive the requirements from the general functionality of the
      selected applications."
   append to section 3.:
     "Please note, that the described applications can have a large
      number of differing implementations. Requirement details or
      requirement significance (MANDATORY (MUST), RECOMMENDED (SHOULD),
      OPTIONAL (MAY)) could differ for specific implementations and/or
      for specific application scenarios. Therefore we derive the
      requirements from the general functionality of the selected
      applications. Some particular cases will even mandate more
      stringent requirements than the ones defined in this
      document. For example, usage-based accounting is certainly the
      application that will probably mandate the highest degree of
      reliability amonst the applications discussed below. The
      reliability reqirements defined in sections 5.1 and 6.3.2. are
      not sufficient to guarantee the level of reliability that is
      needed for many usage-based accounting systems. Particular
      reliability requirements for accounting systems are discussed
      in [RFC2975]."
   add reference to RFC 2975 to References section
========================================================================
Status: solution committed
========================================================================




========================================================================
12. Confidentiality from SHOULD to MUST
========================================================================
Problem Description:
------------------------------------------------------------------------
Requirements on the ipfix implementation - the document is long and I wonder if
the working group really meant the protocol's confidentiality and anonymization
features to be so optional -  SHOULD confidentiality, MAY anonymization.
Just for implementation.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   insert in section 1. Introduction after third sentence:
     "They serve as input to the standardization of an IPFIX protcol."

   append to section 1, Introduction:
     "Many requirements in this document are not explicitly
      stated as IPFIX protocol requirements, but as requirements
      for the metering process, the exporting process, or for
      other traffic measurement components. However, every
      requirement that needs support from the IPFIX protocol
      MUST be covered by the IPFIX protocol specification
      and related standard documents independent of the
      significance of the requirement, which can be MANDATORY (MUST),
      RECOMMENDED (SHOULD), or OPTIONAL (MAY).

      Note that the protocol specification and related standard
      documents themselves also assign significance attributes to its
      features, such that a protocol implementation does not
      necessarily need to implement all features. However, the
      implementations significance atributes need to match those
      of the corresponding IPFIX requirements."
========================================================================
Status: solution committed
========================================================================



========================================================================
13. Anonymization from MAY to MUST
========================================================================
Problem Description:
------------------------------------------------------------------------
Requirements on the ipfix implementation - the document is long and I wonder if
the working group really meant the protocol's confidentiality and anonymization
features to be so optional -  SHOULD confidentiality, MAY anonymization.
Just for implementation.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   see solution of issue 12
========================================================================
Status: solution committed
========================================================================


========================================================================
14. Move paragraph on remote configuration up (out of section 7.2)
========================================================================
Problem Description:
------------------------------------------------------------------------
The paragraph is listed in the subsection on configuration of the
exporting process although it concerns configuration of the metering
process as well as configuration of the exporting process.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   move paragraph up before section 7.1.
========================================================================
Status: solution committed
========================================================================





--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 13 15:33:00 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20784
	for <ipfix-archive@lists.ietf.org>; Fri, 13 Jun 2003 15:32:58 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Qu6G-0007Gm-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 13 Jun 2003 14:20:36 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Qu6F-0007Ge-00
	for ipfix@net.doit.wisc.edu; Fri, 13 Jun 2003 14:20:35 -0500
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5DJKR3p013399;
	Fri, 13 Jun 2003 12:20:28 -0700 (PDT)
Received: from cisco.com (dhcp-171-71-204-251.cisco.com [171.71.204.251]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA21818; Fri, 13 Jun 2003 12:20:27 -0700 (PDT)
Message-ID: <3EEA23FC.B3C2F60E@cisco.com>
Date: Fri, 13 Jun 2003 12:20:28 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tal Givoly <givoly@xacct.com>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] IPFIX-ARCH : Functional flow diagram.
References: <DLEIIIOHMNPJPNMKGEFDOEHCDKAA.givoly@xacct.com>
Content-Type: multipart/alternative;
 boundary="------------14C02BA4A613E5A3E1961813"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


--------------14C02BA4A613E5A3E1961813
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tal,

Aggregation imo should happen in the flow recording proces. But some
rules
of aggreation should also be available to the protocol also for purposes
of
export.

If you look at the EP , it is an abstract entrity that includes the
transport
protocol also. Anonymization is specific to the application and should
be carrier out
in the protocol unless we are dependent on other standard ways to doing
the same.
If we are using some standard ways it should appear between IPFIX
protocol and
transport protocol. Is this correct?
If so I can modify the figure slightly.

Thanks
Ganesh

Tal Givoly wrote:

>  I probably wasn't clear enough... that happens.   What did you mean
> by aggregation? Is it of flows ? Yes, aggregation of flows based on
> some policy.
>    Anonymization IMO is a protocol function and we need to add this to
> the rule and
>    function.I cannot see how anonymization is part of the protocol (or
> the Export Process). The EP should be abstracted from this level of
> detail, as it should from aggregation, sampling, etc.Are the rest of
> the points I made clearer?Tal
>
>      -----Original Message-----
>      From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
>      Sent: Thursday, June 12, 2003 7:20 AM
>      To: Tal Givoly
>      Cc: ipfix@net.doit.wisc.edu
>      Subject: Re: [ipfix] IPFIX-ARCH : Functional flow diagram.
>
>      Tal,
>
>         I agree with you that the diagram does not show the
>      complete interconnects.
>         Sorry, I did not mention that this diagram is in addition
>      to the already existing
>         diagram in the arch spec that shows the interconnects
>      which needs some
>         modification.
>         I was planning to just put the important functions in the
>      diagram and the detail
>         text for each module would  in the different sections.
>      But then maybe we need
>         to still modify the text in the blocks.
>         What did you mean by aggregation? Is it of flows ? There
>      is text in "flow recording
>         process" which mentions about aggregate statistics. But
>      that has nothing to do with
>         aggregation itself.
>         Anonymization IMO is a protocol function and we need to
>      add this to the rule and
>         function.
>
>      Thanks
>      Ganesh
>
>
>      Tal Givoly wrote:
>
>     > Ganesh,Usually, diagrams are useful for illustration of
>     > concepts, but aren't ideal for specification. If you would
>     > like this to be a specification of the inner workings of
>     > the metering process and exporting process, I would
>     > recommend you add the following:- Identification of all
>     > modules and interconnects- Text that describes each of
>     > these modules and interconnects to disambiguate it for the
>     > reader.Regarding the content itself - I believe
>     > aggregation is not clear. Also annonymization location
>     > isn't clear.It seems to me to make more sense to have two
>     > distinct diagrams - one at the high level showing MP (many
>     > to 1) -> EP. Then it would be possible to blow up the MP
>     > and the EP independently and discuss them independently.
>     > The EP depends primarily on the protocol features while
>     > the MP would have the support for most of the capabilities
>     > such as timestamping, and others that you
>     > discuss.Tal-----Original Message-----
>     > From: majordomo listserver
>     > [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Ganesh
>     > Sadasivan
>     > Sent: Wednesday, June 11, 2003 11:58 AM
>     > To: ipfix@net.doit.wisc.edu
>     > Subject: [ipfix] IPFIX-ARCH : Functional flow diagram.
>     >
>     >
>     >      Hi,
>     >         I want to add this figure into the
>     >      architecture spec. Please go through this send
>     >         send any comments/corrections.
>     >
>     >                          Packet(s) coming into
>     >      Observation Point(s)
>     >
>     >      |                                   |
>     >
>     >      |                                   |
>     >
>     >      v                                   v
>     >
>     >      +-----------------+-------------------------+
>     >      +-----+------+
>     >        |           Metering Process on an
>     >      |   |            |
>     >        |              Observation Point
>     >      |   |            |
>     >        |  packet header capturing
>     >      |   |            |
>     >        |         |
>     >      |   | Metering   |
>     >        |    timestamping
>     >      |   | Process    |
>     >        |         |
>     >      |   | on an      |
>     >        |         v
>     >      |   | Observation|
>     >        |  +------+
>     >      |   | Point      |
>     >        |  |      |
>     >      |   |            |
>     >        |  |   sampling Si (1:1 in case of no
>     >      |   |            |
>     >        |  |      |          sampling)
>     >      |   |            |
>     >        |  | classifying Fi (NULL when No criteria)
>     >      |   |            |
>     >        |  |      |
>     >      |   |            |
>     >        |  +------+
>     >      |   |            |
>     >        |         |
>     >      |   |            |
>     >
>     >      +---------+---------------------------------+
>     >      +-----+------+
>     >
>     >      |                                           |
>     >                Flows (identified by observation
>     >      domain)    Flows
>     >
>     >      +----...
>     >      +--------+...
>     >
>     >      |                                           v
>     >                  |
>     >      +-------------------------------------+----------------+
>     >
>     >                  |     |             Flow Recording
>     >      Process(*)                |
>     >                  |     | +----------------------+
>     >      +------------------+    |
>     >                  |     | | Flow data base
>     >      |<----|Provide non-flow  |    |
>     >                  |     | | (includes flows      |
>     >      | information (Eg. |    |
>     >                  |     | | from all obs.        |
>     >      | router state)    |    |
>     >                  |     | | points in an obs.    |
>     >      +------------------+    |.....
>     >                  |     | | domain)
>     >      |                             |
>     >                  |     | |                      |
>     >      +------------------+    |
>     >                  |     | |
>     >      |<----|Maintain aggregate|    |
>     >                  |     | |                      |
>     >      | statistics       |    |
>     >                  |     | +----------------------+
>     >      +------------------+    |
>     >                  |
>     >      +-------------------------------+----------------------+
>     >
>     >
>     >      |                                     |
>     >                  |        Flow Database (identified
>     >      by observation domain)
>     >
>     >      |
>     >      +------------------------....
>     >
>     >      v                                     v
>     >
>     >      -----------+-------------------------------------+--------------------------+
>     >
>     >      |           |            Export
>     >      Process           |                          |
>     >      |
>     >      |
>     >      +----------------------... |
>     >      |
>     >      +---------+------------------------------------------------------------+
>     >      |
>     >      | |         v                  IPFIX
>     >      Protocol                            |   |
>     >      | |+---------------------------------+
>     >      +-------------------------------+|   |
>     >      | || Rules for                       |
>     >      |Functions                      ||   |
>     >      | || - Picking & sending templates   |  |-
>     >      Packetize selected control   ||   |
>     >      | || - Picking & sending data records|->|  &
>     >      data information into      ||   |
>     >      | || - Timing out flows              |  |  IPFIX
>     >      export packet.         ||...|
>     >      | || - Encoding template & data      |  |-
>     >      Handle export errors         ||   |
>     >      | || - Selecting flows for export(*) |  |-
>     >      Handle timeouts & overloads  ||   |
>     >      | |+---------------------------------+
>     >      +-------------------------------+|   |
>     >      |
>     >      |
>     >      |   |
>     >      |
>     >      +-----------------------------+----------------------------------------+
>     >      |
>     >      |
>     >      |                                            |
>     >      |
>     >      +-----------------------------------------...|
>     >      |                     IPFIX exported
>     >      packet                                  |
>     >      |
>     >      |                                            |
>     >      |
>     >      +-----------------------------+----------------------------------------+
>     >      |
>     >      | |                        Transport
>     >      Protocol                           |   |
>     >      |
>     >      +-----------------------------+----------------------------------------+
>     >      |
>     >      |
>     >      |                                            |
>     >
>     >      -------------------------------+--------------------------------------------+
>     >
>     >                                      |
>     >                                      v
>     >                              IPFIX export packet to
>     >      collector.
>     >
>     >      (*) indicates that the block is optional.
>     >
>     >      Thanks
>     >      Ganesh
>     >
>     >
>     >

--------------14C02BA4A613E5A3E1961813
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Tal,
<p>Aggregation imo should happen in the flow recording proces. But some
rules
<br>of aggreation should also be available to the protocol also for purposes
of
<br>export.
<p>If you look at the EP , it is an abstract entrity that includes the
transport
<br>protocol also. Anonymization is specific to the application and should
be carrier out
<br>in the protocol unless we are dependent on other standard ways to doing
the same.
<br>If we are using some standard ways it should appear between IPFIX protocol
and
<br>transport protocol. Is this correct?
<br>If so I can modify the figure slightly.
<p>Thanks
<br>Ganesh
<p>Tal Givoly wrote:
<blockquote TYPE=CITE>&nbsp;<span class=486263422-12062003><font face="Arial"><font color="#0000FF"><font size=-1>I
probably wasn't clear enough... that happens.</font></font></font></span><span class=486263422-12062003>&nbsp;&nbsp;
What did you mean by aggregation?&nbsp;</span><span class=486263422-12062003>Is
it of flows ?&nbsp;</span><span class=486263422-12062003><font face="Arial"><font color="#0000FF"><font size=-1>Yes,
aggregation of flows based on some policy.</font></font></font></span><span class=486263422-12062003>
<br>&nbsp;&nbsp; Anonymization IMO is a protocol function and we need to
add this to the rule and
<br>&nbsp;&nbsp; function.<span class=486263422-12062003></span><span class=486263422-12062003><font face="Arial"><font color="#0000FF"><font size=-1>I
cannot see how anonymization is part of the protocol (or the Export Process).
The EP should be abstracted from this level of detail, as it should from
aggregation, sampling, etc.</font></font></font></span><span class=486263422-12062003></span><span class=486263422-12062003><font face="Arial"><font color="#0000FF"><font size=-1>Are
the rest of the points I made clearer?</font></font></font></span><span class=486263422-12062003></span><span class=486263422-12062003><font face="Arial"><font color="#0000FF"><font size=-1>Tal</font></font></font></span></span><span class=486263422-12062003></span>
<blockquote dir=ltr style="MARGIN-RIGHT: 0px">
<div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Ganesh Sadasivan [<A HREF="mailto:gsadasiv@cisco.com">mailto:gsadasiv@cisco.com</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Thursday, June 12, 2003
7:20 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> Tal Givoly</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> ipfix@net.doit.wisc.edu</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> Re: [ipfix] IPFIX-ARCH
: Functional flow diagram.</font></font>
<br>&nbsp;</div>
Tal,
<p>&nbsp;&nbsp; I agree with you that the diagram does not show the complete
interconnects.
<br>&nbsp;&nbsp; Sorry, I did not mention that this diagram is in addition
to the already existing
<br>&nbsp;&nbsp; diagram in the arch spec that shows the interconnects
which needs some
<br>&nbsp;&nbsp; modification.
<br>&nbsp;&nbsp; I was planning to just put the important functions in
the diagram and the detail
<br>&nbsp;&nbsp; text for each module would&nbsp; in the different sections.
But then maybe we need
<br>&nbsp;&nbsp; to still modify the text in the blocks.
<br>&nbsp;&nbsp; What did you mean by aggregation? Is it of flows ? There
is text in "flow recording
<br>&nbsp;&nbsp; process" which mentions about aggregate statistics. But
that has nothing to do with
<br>&nbsp;&nbsp; aggregation itself.
<br>&nbsp;&nbsp; Anonymization IMO is a protocol function and we need to
add this to the rule and
<br>&nbsp;&nbsp; function.
<p>Thanks
<br>Ganesh
<br>&nbsp;
<p>Tal Givoly wrote:
<blockquote TYPE="CITE"><span class=796145803-12062003><font size=-1><font face="Arial"><font color="#0000FF">Ganesh,</span><span 
    class=796145803-12062003></span><span class=796145803-12062003>Usually,
diagrams are useful for illustration of concepts, but aren't ideal for
specification. If you would like this to be a specification of the inner
workings of the metering process and exporting process, I would recommend
you add the following:</span><span class=796145803-12062003>- Identification
of all modules and interconnects</span><span 
    class=796145803-12062003>-
Text that describes each of these modules and interconnects to disambiguate
it for the reader.</span><span 
    class=796145803-12062003></span><span class=796145803-12062003>Regarding
the content itself - I believe aggregation is not clear. Also annonymization
location isn't clear.</span><span 
    class=796145803-12062003></span><span class=796145803-12062003>It
seems to me to make more sense to have two distinct diagrams - one at the
high level showing MP (many to 1) -> EP. Then it would be possible to blow
up the MP and the EP independently and discuss them independently. The
EP depends primarily on the protocol features while the MP would have the
support for most of the capabilities such as timestamping, and others that
you discuss.</span><span 
    class=796145803-12062003></span><span class=796145803-12062003>Tal</span><span 
    class=796145803-12062003></span></font></font><font face="Tahoma">-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> majordomo listserver
[<a href="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</a>]<b>On
Behalf Of </b>Ganesh Sadasivan</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Wednesday, June 11,
2003 11:58 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> ipfix@net.doit.wisc.edu</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> [ipfix] IPFIX-ARCH
: Functional flow diagram.</font></font>
<br>&nbsp;
<blockquote dir=ltr style="MARGIN-RIGHT: 0px"><tt>Hi,</tt>
<br><tt>&nbsp;&nbsp; I want to add this figure into the architecture spec.
Please go through this send</tt>
<br><tt>&nbsp;&nbsp; send any comments/corrections.</tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Packet(s) coming into Observation Point(s)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>&nbsp; +-----------------+-------------------------+&nbsp;&nbsp;
+-----+------+</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Metering Process on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Observation Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; packet header capturing&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Metering&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp; timestamping&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Process&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | on an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Observation|</tt>
<br><tt>&nbsp; |&nbsp; +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; | Point&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp; sampling Si (1:1 in case of no&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sampling)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; | classifying Fi (NULL when No criteria) |&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp; +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp; +---------+---------------------------------+&nbsp;&nbsp;
+-----+------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flows (identified
by observation domain)&nbsp;&nbsp;&nbsp; Flows</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+--------+...</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; +-------------------------------------+----------------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Flow Recording Process(*)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | +----------------------+&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | Flow data base&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;----|Provide non-flow&nbsp; |&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | (includes flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | information (Eg. |&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | from all obs.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | router state)&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | points in an obs.&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp;&nbsp;&nbsp; |.....</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | | domain)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; +------------------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;----|Maintain aggregate|&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | statistics&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; | +----------------------+&nbsp;&nbsp;&nbsp;&nbsp;
+------------------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; +-------------------------------+----------------------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flow Database (identified by
observation domain)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+------------------------....</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>+-----------+-------------------------------------+--------------------------+</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Export Process&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----------------------... |</tt>
<br><tt>| +---------+------------------------------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IPFIX Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |</tt>
<br><tt>| |+---------------------------------+&nbsp; +-------------------------------+|&nbsp;&nbsp;
|</tt>
<br><tt>| || Rules for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |Functions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp; |</tt>
<br><tt>| || - Picking &amp; sending templates&nbsp;&nbsp; |&nbsp; |- Packetize
selected control&nbsp;&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| || - Picking &amp; sending data records|->|&nbsp; &amp; data
information into&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| || - Timing out flows&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |&nbsp; IPFIX export packet.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||...|</tt>
<br><tt>| || - Encoding template &amp; data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; |- Handle export errors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp; |</tt>
<br><tt>| || - Selecting flows for export(*) |&nbsp; |- Handle timeouts
&amp; overloads&nbsp; ||&nbsp;&nbsp; |</tt>
<br><tt>| |+---------------------------------+&nbsp; +-------------------------------+|&nbsp;&nbsp;
|</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |</tt>
<br><tt>| +-----------------------------+----------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----------------------------------------...|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IPFIX exported packet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>| +-----------------------------+----------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Transport&nbsp; Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |</tt>
<br><tt>| +-----------------------------+----------------------------------------+&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>+-------------------------------+--------------------------------------------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IPFIX export packet to collector.</tt>
<p><tt>(*) indicates that the block is optional.</tt>
<p><tt>Thanks</tt>
<br><tt>Ganesh</tt>
<br>&nbsp;
<br>&nbsp;</blockquote>
</blockquote>
</blockquote>
</blockquote>
</html>

--------------14C02BA4A613E5A3E1961813--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 16 15:59:15 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28914
	for <ipfix-archive@lists.ietf.org>; Mon, 16 Jun 2003 15:59:15 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Rzlj-0007Su-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 16 Jun 2003 14:35:55 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Rzli-0007Sj-00
	for ipfix@net.doit.wisc.edu; Mon, 16 Jun 2003 14:35:54 -0500
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5GJZpTa007191
	for <ipfix@net.doit.wisc.edu>; Mon, 16 Jun 2003 12:35:52 -0700 (PDT)
Received: from cisco.com (dhcp-171-71-204-251.cisco.com [171.71.204.251]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA26124 for <ipfix@net.doit.wisc.edu>; Mon, 16 Jun 2003 12:35:51 -0700 (PDT)
Message-ID: <3EEE1C17.CA68B679@cisco.com>
Date: Mon, 16 Jun 2003 12:35:51 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [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] Exporting Control Information
References: <DLEIIIOHMNPJPNMKGEFDOEHCDKAA.givoly@xacct.com> <3EEA23FC.B3C2F60E@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Hi,

   The following text describes the architecture for exporting control
   information. The protocol should have it own section on this topic.
   Please let me know your thoughts on the paragraphs below.

Exporting Control Information

   The Control Information is used by the collector to :
   - decode and interpret flow records.
   - understand the exporter state.

   As such sending control information from exporter in a timely and
   reliable manner is critical to the proper functionality of the IPFIX
   collector. The following approaches MAY be taken for the export of
   control information.

     1. Send all the control information pertaining to flow records
        prior to sending the flow records themselves. This includes any
        incremental changes that happens to the definition of the flow
        records.

     2. Notify on a near real time basis the state of the exporter to
        the collector. This includes all the changes like a
        configuration change that affects the flow behavior, changes to
        exporter resources that affects export rates, etc that which the

        collector needs to be aware of.

     3. For the reasons 1. and 2. it is preferred that the export of
        Control Information be done over a reliable connection. This MAY

        be done through a reliable transport or a partially reliable
        transport when the underlying network is reliable.

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  Tue Jun 17 00:26:56 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16499
	for <ipfix-archive@lists.ietf.org>; Tue, 17 Jun 2003 00:26:55 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19S7sG-0006CI-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 16 Jun 2003 23:15:12 -0500
Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19S7sF-0006CD-00
	for ipfix@net.doit.wisc.edu; Mon, 16 Jun 2003 23:15:11 -0500
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28])
	by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5H4Eem18950;
	Mon, 16 Jun 2003 21:14:40 -0700 (PDT)
Received: from zsc3c026.us.nortel.com ([47.81.138.26]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id NALGRZ3V; Mon, 16 Jun 2003 21:14:25 -0700
Received: from private2xsth6c (artpt5n5.us.nortel.com [47.140.52.57]) by zsc3c026.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id J4HAL7TR; Mon, 16 Jun 2003 21:14:25 -0700
Message-ID: <000701c33486$f6bb7c10$39348c2f@private2xsth6c>
X-Sybari-Space: 00000000 00000000 00000000
From: "Reinaldo Penno" <rpenno@nortelnetworks.com>
To: "Ganesh Sadasivan" <gsadasiv@cisco.com>, <ipfix@net.doit.wisc.edu>
References: <DLEIIIOHMNPJPNMKGEFDOEHCDKAA.givoly@xacct.com> <3EEA23FC.B3C2F60E@cisco.com> <3EEE1C17.CA68B679@cisco.com>
Subject: Re: [ipfix] Exporting Control Information
Date: Tue, 17 Jun 2003 00:14:35 -0400
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 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Hello Ganesh,

I guess everything looks okay except number 3...Some comments

You say that is it preferred that the export de done over a reliable
connection. Do you mean IPfix connection? If it the "preferred" method I
guess a SHOULD would be more appropriated.

Using terms like "partially reliable" could be opening a can of worms...What
is a partially reliable transport? And what you mean that the network is
reliable?

Anyway, my overall suggestion is to rewrite number 3 to make it less
ambiguous and open to interpretation.

regards,

Reinaldo

>      3. For the reasons 1. and 2. it is preferred that the export of
>         Control Information be done over a reliable connection. This MAY
>
>         be done through a reliable transport or a partially reliable
>         transport when the underlying network is reliable.


----- Original Message ----- 
From: "Ganesh Sadasivan" <gsadasiv@cisco.com>
To: <ipfix@net.doit.wisc.edu>
Sent: Monday, June 16, 2003 3:35 PM
Subject: [ipfix] Exporting Control Information


> Hi,
>
>    The following text describes the architecture for exporting control
>    information. The protocol should have it own section on this topic.
>    Please let me know your thoughts on the paragraphs below.
>
> Exporting Control Information
>
>    The Control Information is used by the collector to :
>    - decode and interpret flow records.
>    - understand the exporter state.
>
>    As such sending control information from exporter in a timely and
>    reliable manner is critical to the proper functionality of the IPFIX
>    collector. The following approaches MAY be taken for the export of
>    control information.
>
>      1. Send all the control information pertaining to flow records
>         prior to sending the flow records themselves. This includes any
>         incremental changes that happens to the definition of the flow
>         records.
>
>      2. Notify on a near real time basis the state of the exporter to
>         the collector. This includes all the changes like a
>         configuration change that affects the flow behavior, changes to
>         exporter resources that affects export rates, etc that which the
>
>         collector needs to be aware of.
>
>      3. For the reasons 1. and 2. it is preferred that the export of
>         Control Information be done over a reliable connection. This MAY
>
>         be done through a reliable transport or a partially reliable
>         transport when the underlying network is reliable.
>
> 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/


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 17 16:10:19 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08669
	for <ipfix-archive@lists.ietf.org>; Tue, 17 Jun 2003 16:10:19 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19SMOX-0000ln-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 17 Jun 2003 14:45:29 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19SMOW-0000lg-00
	for ipfix@net.doit.wisc.edu; Tue, 17 Jun 2003 14:45:28 -0500
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5HJjPpa015605;
	Tue, 17 Jun 2003 12:45:25 -0700 (PDT)
Received: from cisco.com (dhcp-171-71-204-251.cisco.com [171.71.204.251]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA27720; Tue, 17 Jun 2003 12:45:25 -0700 (PDT)
Message-ID: <3EEF6FD4.6477245D@cisco.com>
Date: Tue, 17 Jun 2003 12:45:25 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Reinaldo Penno <rpenno@nortelnetworks.com>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Exporting Control Information
References: <DLEIIIOHMNPJPNMKGEFDOEHCDKAA.givoly@xacct.com> <3EEA23FC.B3C2F60E@cisco.com> <3EEE1C17.CA68B679@cisco.com> <000701c33486$f6bb7c10$39348c2f@private2xsth6c>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Hi Reinaldo,

   I agree that the statements are fuzzy. How about this one?

  For the reasons 1. and 2., the export of the control information
  SHOULD be done such that the it reaches the collector reliably.
  One way to achieve this would be  to send the control
  information over a reliable transport.

Thanks
Ganesh

Reinaldo Penno wrote:

> Hello Ganesh,
>
> I guess everything looks okay except number 3...Some comments
>
> You say that is it preferred that the export de done over a reliable
> connection. Do you mean IPfix connection? If it the "preferred" method I
> guess a SHOULD would be more appropriated.
>
> Using terms like "partially reliable" could be opening a can of worms...What
> is a partially reliable transport? And what you mean that the network is
> reliable?
>
> Anyway, my overall suggestion is to rewrite number 3 to make it less
> ambiguous and open to interpretation.
>
> regards,
>
> Reinaldo
>
> >      3. For the reasons 1. and 2. it is preferred that the export of
> >         Control Information be done over a reliable connection. This MAY
> >
> >         be done through a reliable transport or a partially reliable
> >         transport when the underlying network is reliable.
>
> ----- Original Message -----
> From: "Ganesh Sadasivan" <gsadasiv@cisco.com>
> To: <ipfix@net.doit.wisc.edu>
> Sent: Monday, June 16, 2003 3:35 PM
> Subject: [ipfix] Exporting Control Information
>
> > Hi,
> >
> >    The following text describes the architecture for exporting control
> >    information. The protocol should have it own section on this topic.
> >    Please let me know your thoughts on the paragraphs below.
> >
> > Exporting Control Information
> >
> >    The Control Information is used by the collector to :
> >    - decode and interpret flow records.
> >    - understand the exporter state.
> >
> >    As such sending control information from exporter in a timely and
> >    reliable manner is critical to the proper functionality of the IPFIX
> >    collector. The following approaches MAY be taken for the export of
> >    control information.
> >
> >      1. Send all the control information pertaining to flow records
> >         prior to sending the flow records themselves. This includes any
> >         incremental changes that happens to the definition of the flow
> >         records.
> >
> >      2. Notify on a near real time basis the state of the exporter to
> >         the collector. This includes all the changes like a
> >         configuration change that affects the flow behavior, changes to
> >         exporter resources that affects export rates, etc that which the
> >
> >         collector needs to be aware of.
> >
> >      3. For the reasons 1. and 2. it is preferred that the export of
> >         Control Information be done over a reliable connection. This MAY
> >
> >         be done through a reliable transport or a partially reliable
> >         transport when the underlying network is reliable.
> >
> > 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/
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" 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 Jun 17 16:29:43 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09521
	for <ipfix-archive@lists.ietf.org>; Tue, 17 Jun 2003 16:29:42 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19SMZu-00016l-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 17 Jun 2003 14:57:14 -0500
Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19SMZt-00016d-00
	for ipfix@net.doit.wisc.edu; Tue, 17 Jun 2003 14:57:13 -0500
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28])
	by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5HJv3m11430;
	Tue, 17 Jun 2003 12:57:04 -0700 (PDT)
Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <NALGTFBY>; Tue, 17 Jun 2003 12:57:03 -0700
Message-ID: <0A11633F61BD9F40B43ABCC694004F930218EF98@zsc3c026.us.nortel.com>
From: "Reinaldo Penno" <rpenno@nortelnetworks.com>
To: "'Ganesh Sadasivan'" <gsadasiv@cisco.com>
Cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] Exporting Control Information
Date: Tue, 17 Jun 2003 12:57:03 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3350A.4DAECDB4"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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_01C3350A.4DAECDB4
Content-Type: text/plain;
	charset="iso-8859-1"

How about we simplify even more? IMO we could do away with the "reaches". We
just say that it has to be reliable and one of the methods is using a
reliable transport. If someone has a different method but it is also
reliable then it is okay.

   For the reasons 1. and 2., the export of the control information
   SHOULD be done reliably.
   One way to achieve this would be  to send the control
   information over a reliable transport.

> -----Original Message-----
> From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] 
> Sent: Tuesday, June 17, 2003 3:45 PM
> To: Penno, Reinaldo [BL60:SB20:EXCH]
> Cc: ipfix@net.doit.wisc.edu
> Subject: Re: [ipfix] Exporting Control Information
> 
> 
> Hi Reinaldo,
> 
>    I agree that the statements are fuzzy. How about this one?
> 
>   For the reasons 1. and 2., the export of the control information
>   SHOULD be done such that the it reaches the collector reliably.
>   One way to achieve this would be  to send the control
>   information over a reliable transport.
> 
> Thanks
> Ganesh
> 
> Reinaldo Penno wrote:
> 
> > Hello Ganesh,
> >
> > I guess everything looks okay except number 3...Some comments
> >
> > You say that is it preferred that the export de done over a 
> reliable 
> > connection. Do you mean IPfix connection? If it the 
> "preferred" method 
> > I guess a SHOULD would be more appropriated.
> >
> > Using terms like "partially reliable" could be opening a can of 
> > worms...What is a partially reliable transport? And what 
> you mean that 
> > the network is reliable?
> >
> > Anyway, my overall suggestion is to rewrite number 3 to 
> make it less 
> > ambiguous and open to interpretation.
> >
> > regards,
> >
> > Reinaldo
> >
> > >      3. For the reasons 1. and 2. it is preferred that 
> the export of
> > >         Control Information be done over a reliable 
> connection. This 
> > > MAY
> > >
> > >         be done through a reliable transport or a 
> partially reliable
> > >         transport when the underlying network is reliable.
> >
> > ----- Original Message -----
> > From: "Ganesh Sadasivan" <gsadasiv@cisco.com>
> > To: <ipfix@net.doit.wisc.edu>
> > Sent: Monday, June 16, 2003 3:35 PM
> > Subject: [ipfix] Exporting Control Information
> >
> > > Hi,
> > >
> > >    The following text describes the architecture for 
> exporting control
> > >    information. The protocol should have it own section 
> on this topic.
> > >    Please let me know your thoughts on the paragraphs below.
> > >
> > > Exporting Control Information
> > >
> > >    The Control Information is used by the collector to :
> > >    - decode and interpret flow records.
> > >    - understand the exporter state.
> > >
> > >    As such sending control information from exporter in a 
> timely and
> > >    reliable manner is critical to the proper 
> functionality of the IPFIX
> > >    collector. The following approaches MAY be taken for 
> the export of
> > >    control information.
> > >
> > >      1. Send all the control information pertaining to 
> flow records
> > >         prior to sending the flow records themselves. 
> This includes any
> > >         incremental changes that happens to the 
> definition of the flow
> > >         records.
> > >
> > >      2. Notify on a near real time basis the state of the 
> exporter to
> > >         the collector. This includes all the changes like a
> > >         configuration change that affects the flow 
> behavior, changes to
> > >         exporter resources that affects export rates, etc 
> that which 
> > > the
> > >
> > >         collector needs to be aware of.
> > >
> > >      3. For the reasons 1. and 2. it is preferred that 
> the export of
> > >         Control Information be done over a reliable 
> connection. This 
> > > MAY
> > >
> > >         be done through a reliable transport or a 
> partially reliable
> > >         transport when the underlying network is reliable.
> > >
> > > 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/
> >
> > --
> > Help        mailto:majordomo@net.doit.wisc.edu and say 
> "help" 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_01C3350A.4DAECDB4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [ipfix] Exporting Control Information</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>How about we simplify even more? IMO we could do away =
with the &quot;reaches&quot;. We just say that it has to be reliable =
and one of the methods is using a reliable transport. If someone has a =
different method but it is also reliable then it is okay.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; For the reasons 1. and 2., the export of =
the control information</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; SHOULD be done reliably.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; One way to achieve this would be&nbsp; =
to send the control</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; information over a reliable =
transport.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Ganesh Sadasivan [<A =
HREF=3D"mailto:gsadasiv@cisco.com">mailto:gsadasiv@cisco.com</A>] =
</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, June 17, 2003 3:45 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Penno, Reinaldo [BL60:SB20:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: ipfix@net.doit.wisc.edu</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [ipfix] Exporting Control =
Information</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi Reinaldo,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; I agree that the statements =
are fuzzy. How about this one?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; For the reasons 1. and 2., the =
export of the control information</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; SHOULD be done such that the it =
reaches the collector reliably.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; One way to achieve this would =
be&nbsp; to send the control</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; information over a reliable =
transport.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks</FONT>
<BR><FONT SIZE=3D2>&gt; Ganesh</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Reinaldo Penno wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hello Ganesh,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I guess everything looks okay except =
number 3...Some comments</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; You say that is it preferred that the =
export de done over a </FONT>
<BR><FONT SIZE=3D2>&gt; reliable </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; connection. Do you mean IPfix connection? =
If it the </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;preferred&quot; method </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I guess a SHOULD would be more =
appropriated.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Using terms like &quot;partially =
reliable&quot; could be opening a can of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; worms...What is a partially reliable =
transport? And what </FONT>
<BR><FONT SIZE=3D2>&gt; you mean that </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the network is reliable?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Anyway, my overall suggestion is to =
rewrite number 3 to </FONT>
<BR><FONT SIZE=3D2>&gt; make it less </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ambiguous and open to =
interpretation.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; regards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Reinaldo</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. For =
the reasons 1. and 2. it is preferred that </FONT>
<BR><FONT SIZE=3D2>&gt; the export of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Control =
Information be done over a reliable </FONT>
<BR><FONT SIZE=3D2>&gt; connection. This </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; MAY</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; be done through a =
reliable transport or a </FONT>
<BR><FONT SIZE=3D2>&gt; partially reliable</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transport when the =
underlying network is reliable.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: &quot;Ganesh Sadasivan&quot; =
&lt;gsadasiv@cisco.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: &lt;ipfix@net.doit.wisc.edu&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Monday, June 16, 2003 3:35 PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: [ipfix] Exporting Control =
Information</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; The following text =
describes the architecture for </FONT>
<BR><FONT SIZE=3D2>&gt; exporting control</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; information. The =
protocol should have it own section </FONT>
<BR><FONT SIZE=3D2>&gt; on this topic.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; Please let me know =
your thoughts on the paragraphs below.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Exporting Control Information</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; The Control =
Information is used by the collector to :</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; - decode and =
interpret flow records.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; - understand the =
exporter state.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; As such sending =
control information from exporter in a </FONT>
<BR><FONT SIZE=3D2>&gt; timely and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; reliable manner is =
critical to the proper </FONT>
<BR><FONT SIZE=3D2>&gt; functionality of the IPFIX</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; collector. The =
following approaches MAY be taken for </FONT>
<BR><FONT SIZE=3D2>&gt; the export of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; control =
information.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. Send =
all the control information pertaining to </FONT>
<BR><FONT SIZE=3D2>&gt; flow records</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; prior to sending =
the flow records themselves. </FONT>
<BR><FONT SIZE=3D2>&gt; This includes any</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; incremental =
changes that happens to the </FONT>
<BR><FONT SIZE=3D2>&gt; definition of the flow</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; records.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2. =
Notify on a near real time basis the state of the </FONT>
<BR><FONT SIZE=3D2>&gt; exporter to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the collector. =
This includes all the changes like a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; configuration =
change that affects the flow </FONT>
<BR><FONT SIZE=3D2>&gt; behavior, changes to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exporter resources =
that affects export rates, etc </FONT>
<BR><FONT SIZE=3D2>&gt; that which </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; collector needs to =
be aware of.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. For =
the reasons 1. and 2. it is preferred that </FONT>
<BR><FONT SIZE=3D2>&gt; the export of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Control =
Information be done over a reliable </FONT>
<BR><FONT SIZE=3D2>&gt; connection. This </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; MAY</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; be done through a =
reliable transport or a </FONT>
<BR><FONT SIZE=3D2>&gt; partially reliable</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transport when the =
underlying network is reliable.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Thanks</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Ganesh</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
Help&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wi=
sc.edu</A> and say </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;help&quot; in message</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; body</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Unsubscribe <A =
HREF=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wi=
sc.edu</A> and say </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;unsubscribe </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ipfix&quot; in message body</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Archive&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://ipfix.doit.wisc.edu/archive/" =
TARGET=3D"_blank">http://ipfix.doit.wisc.edu/archive/</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
Help&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wi=
sc.edu</A> and say </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;help&quot; in message body</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Unsubscribe <A =
HREF=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wi=
sc.edu</A> and say &quot;unsubscribe </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ipfix&quot; in message body</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Archive&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://ipfix.doit.wisc.edu/archive/" =
TARGET=3D"_blank">http://ipfix.doit.wisc.edu/archive/</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3350A.4DAECDB4--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 17 16:33:33 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09883
	for <ipfix-archive@lists.ietf.org>; Tue, 17 Jun 2003 16:33:32 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19SMoK-0001Zf-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 17 Jun 2003 15:12:08 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19SMoJ-0001ZS-00
	for ipfix@net.doit.wisc.edu; Tue, 17 Jun 2003 15:12:07 -0500
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5HKC5Um020664;
	Tue, 17 Jun 2003 13:12:05 -0700 (PDT)
Received: from cisco.com (dhcp-171-71-204-251.cisco.com [171.71.204.251]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA27780; Tue, 17 Jun 2003 13:12:05 -0700 (PDT)
Message-ID: <3EEF7614.3B8D4009@cisco.com>
Date: Tue, 17 Jun 2003 13:12:04 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Reinaldo Penno <rpenno@nortelnetworks.com>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Exporting Control Information
References: <0A11633F61BD9F40B43ABCC694004F930218EF98@zsc3c026.us.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------B03E77248C6D228C54B01E8F"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


--------------B03E77248C6D228C54B01E8F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Reinaldo Penno wrote:

>
>
> How about we simplify even more? IMO we could do away with the
> "reaches". We just say that it has to be reliable and one of the
> methods is using a reliable transport. If someone has a different
> method but it is also reliable then it is okay.
>
>    For the reasons 1. and 2., the export of the control information
>    SHOULD be done reliably.

I initially wrote this sentence before sending the e-mail. But this
sentence is
partial in the sense that it does not talk about the receiver getting
information
reliably. So is it not prone to mis-interpretation?

-ganesh

>
>    One way to achieve this would be  to send the control
>    information over a reliable transport.
>
> > -----Original Message-----
> > From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
> > Sent: Tuesday, June 17, 2003 3:45 PM
> > To: Penno, Reinaldo [BL60:SB20:EXCH]
> > Cc: ipfix@net.doit.wisc.edu
> > Subject: Re: [ipfix] Exporting Control Information
> >
> >
> > Hi Reinaldo,
> >
> >    I agree that the statements are fuzzy. How about this one?
> >
> >   For the reasons 1. and 2., the export of the control information
> >   SHOULD be done such that the it reaches the collector reliably.
> >   One way to achieve this would be  to send the control
> >   information over a reliable transport.
> >
> > Thanks
> > Ganesh
> >
> > Reinaldo Penno wrote:
> >
> > > Hello Ganesh,
> > >
> > > I guess everything looks okay except number 3...Some comments
> > >
> > > You say that is it preferred that the export de done over a
> > reliable
> > > connection. Do you mean IPfix connection? If it the
> > "preferred" method
> > > I guess a SHOULD would be more appropriated.
> > >
> > > Using terms like "partially reliable" could be opening a can of
> > > worms...What is a partially reliable transport? And what
> > you mean that
> > > the network is reliable?
> > >
> > > Anyway, my overall suggestion is to rewrite number 3 to
> > make it less
> > > ambiguous and open to interpretation.
> > >
> > > regards,
> > >
> > > Reinaldo
> > >
> > > >      3. For the reasons 1. and 2. it is preferred that
> > the export of
> > > >         Control Information be done over a reliable
> > connection. This
> > > > MAY
> > > >
> > > >         be done through a reliable transport or a
> > partially reliable
> > > >         transport when the underlying network is reliable.
> > >
> > > ----- Original Message -----
> > > From: "Ganesh Sadasivan" <gsadasiv@cisco.com>
> > > To: <ipfix@net.doit.wisc.edu>
> > > Sent: Monday, June 16, 2003 3:35 PM
> > > Subject: [ipfix] Exporting Control Information
> > >
> > > > Hi,
> > > >
> > > >    The following text describes the architecture for
> > exporting control
> > > >    information. The protocol should have it own section
> > on this topic.
> > > >    Please let me know your thoughts on the paragraphs below.
> > > >
> > > > Exporting Control Information
> > > >
> > > >    The Control Information is used by the collector to :
> > > >    - decode and interpret flow records.
> > > >    - understand the exporter state.
> > > >
> > > >    As such sending control information from exporter in a
> > timely and
> > > >    reliable manner is critical to the proper
> > functionality of the IPFIX
> > > >    collector. The following approaches MAY be taken for
> > the export of
> > > >    control information.
> > > >
> > > >      1. Send all the control information pertaining to
> > flow records
> > > >         prior to sending the flow records themselves.
> > This includes any
> > > >         incremental changes that happens to the
> > definition of the flow
> > > >         records.
> > > >
> > > >      2. Notify on a near real time basis the state of the
> > exporter to
> > > >         the collector. This includes all the changes like a
> > > >         configuration change that affects the flow
> > behavior, changes to
> > > >         exporter resources that affects export rates, etc
> > that which
> > > > the
> > > >
> > > >         collector needs to be aware of.
> > > >
> > > >      3. For the reasons 1. and 2. it is preferred that
> > the export of
> > > >         Control Information be done over a reliable
> > connection. This
> > > > MAY
> > > >
> > > >         be done through a reliable transport or a
> > partially reliable
> > > >         transport when the underlying network is reliable.
> > > >
> > > > 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/
> > >
> > > --
> > > Help        mailto:majordomo@net.doit.wisc.edu and say
> > "help" in message body
> > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe
> > > ipfix" in message body
> > > Archive     http://ipfix.doit.wisc.edu/archive/
> >
> >

--------------B03E77248C6D228C54B01E8F
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>Reinaldo Penno wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font size=-1>How about we simplify even more? IMO we could do away
with the "reaches". We just say that it has to be reliable and one of the
methods is using a reliable transport. If someone has a different method
but it is also reliable then it is okay.</font>
<p><font size=-1>&nbsp;&nbsp; For the reasons 1. and 2., the export of
the control information</font>
<br><font size=-1>&nbsp;&nbsp; SHOULD be done reliably.</font></blockquote>
I initially wrote this sentence before sending the e-mail. But this sentence
is
<br>partial in the sense that it does not talk about the receiver getting
information
<br>reliably. So is it not prone to mis-interpretation?
<p>-ganesh
<blockquote TYPE=CITE><font size=-1></font>&nbsp;
<br><font size=-1>&nbsp;&nbsp; One way to achieve this would be&nbsp; to
send the control</font>
<br><font size=-1>&nbsp;&nbsp; information over a reliable transport.</font>
<p><font size=-1>> -----Original Message-----</font>
<br><font size=-1>> From: Ganesh Sadasivan [<a href="mailto:gsadasiv@cisco.com">mailto:gsadasiv@cisco.com</a>]</font>
<br><font size=-1>> Sent: Tuesday, June 17, 2003 3:45 PM</font>
<br><font size=-1>> To: Penno, Reinaldo [BL60:SB20:EXCH]</font>
<br><font size=-1>> Cc: ipfix@net.doit.wisc.edu</font>
<br><font size=-1>> Subject: Re: [ipfix] Exporting Control Information</font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>> Hi Reinaldo,</font>
<br><font size=-1>></font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp; I agree that the statements are fuzzy.
How about this one?</font>
<br><font size=-1>></font>
<br><font size=-1>>&nbsp;&nbsp; For the reasons 1. and 2., the export of
the control information</font>
<br><font size=-1>>&nbsp;&nbsp; SHOULD be done such that the it reaches
the collector reliably.</font>
<br><font size=-1>>&nbsp;&nbsp; One way to achieve this would be&nbsp;
to send the control</font>
<br><font size=-1>>&nbsp;&nbsp; information over a reliable transport.</font>
<br><font size=-1>></font>
<br><font size=-1>> Thanks</font>
<br><font size=-1>> Ganesh</font>
<br><font size=-1>></font>
<br><font size=-1>> Reinaldo Penno wrote:</font>
<br><font size=-1>></font>
<br><font size=-1>> > Hello Ganesh,</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > I guess everything looks okay except number 3...Some
comments</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > You say that is it preferred that the export de done
over a</font>
<br><font size=-1>> reliable</font>
<br><font size=-1>> > connection. Do you mean IPfix connection? If it the</font>
<br><font size=-1>> "preferred" method</font>
<br><font size=-1>> > I guess a SHOULD would be more appropriated.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Using terms like "partially reliable" could be opening
a can of</font>
<br><font size=-1>> > worms...What is a partially reliable transport? And
what</font>
<br><font size=-1>> you mean that</font>
<br><font size=-1>> > the network is reliable?</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Anyway, my overall suggestion is to rewrite number
3 to</font>
<br><font size=-1>> make it less</font>
<br><font size=-1>> > ambiguous and open to interpretation.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > regards,</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Reinaldo</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. For the reasons
1. and 2. it is preferred that</font>
<br><font size=-1>> the export of</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Control Information be done over a reliable</font>
<br><font size=-1>> connection. This</font>
<br><font size=-1>> > > MAY</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
be done through a reliable transport or a</font>
<br><font size=-1>> partially reliable</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
transport when the underlying network is reliable.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > ----- Original Message -----</font>
<br><font size=-1>> > From: "Ganesh Sadasivan" &lt;gsadasiv@cisco.com></font>
<br><font size=-1>> > To: &lt;ipfix@net.doit.wisc.edu></font>
<br><font size=-1>> > Sent: Monday, June 16, 2003 3:35 PM</font>
<br><font size=-1>> > Subject: [ipfix] Exporting Control Information</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > > Hi,</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp; The following text describes
the architecture for</font>
<br><font size=-1>> exporting control</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp; information. The protocol should
have it own section</font>
<br><font size=-1>> on this topic.</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp; Please let me know your thoughts
on the paragraphs below.</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > Exporting Control Information</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp; The Control Information is used
by the collector to :</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp; - decode and interpret flow records.</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp; - understand the exporter state.</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp; As such sending control information
from exporter in a</font>
<br><font size=-1>> timely and</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp; reliable manner is critical to
the proper</font>
<br><font size=-1>> functionality of the IPFIX</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp; collector. The following approaches
MAY be taken for</font>
<br><font size=-1>> the export of</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp; control information.</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. Send all the control
information pertaining to</font>
<br><font size=-1>> flow records</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
prior to sending the flow records themselves.</font>
<br><font size=-1>> This includes any</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
incremental changes that happens to the</font>
<br><font size=-1>> definition of the flow</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
records.</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2. Notify on a near
real time basis the state of the</font>
<br><font size=-1>> exporter to</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
the collector. This includes all the changes like a</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
configuration change that affects the flow</font>
<br><font size=-1>> behavior, changes to</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
exporter resources that affects export rates, etc</font>
<br><font size=-1>> that which</font>
<br><font size=-1>> > > the</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
collector needs to be aware of.</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. For the reasons
1. and 2. it is preferred that</font>
<br><font size=-1>> the export of</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Control Information be done over a reliable</font>
<br><font size=-1>> connection. This</font>
<br><font size=-1>> > > MAY</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
be done through a reliable transport or a</font>
<br><font size=-1>> partially reliable</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
transport when the underlying network is reliable.</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > Thanks</font>
<br><font size=-1>> > > Ganesh</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > --</font>
<br><font size=-1>> > > Help&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a>
and say</font>
<br><font size=-1>> "help" in message</font>
<br><font size=-1>> > body</font>
<br><font size=-1>> > > Unsubscribe <a href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a>
and say</font>
<br><font size=-1>> "unsubscribe</font>
<br><font size=-1>> > > ipfix" in message body</font>
<br><font size=-1>> > > Archive&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://ipfix.doit.wisc.edu/archive/" TARGET="_blank">http://ipfix.doit.wisc.edu/archive/</a></font>
<br><font size=-1>> ></font>
<br><font size=-1>> > --</font>
<br><font size=-1>> > Help&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a>
and say</font>
<br><font size=-1>> "help" in message body</font>
<br><font size=-1>> > Unsubscribe <a href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a>
and say "unsubscribe</font>
<br><font size=-1>> > ipfix" in message body</font>
<br><font size=-1>> > Archive&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://ipfix.doit.wisc.edu/archive/" TARGET="_blank">http://ipfix.doit.wisc.edu/archive/</a></font>
<br><font size=-1>></font>
<br><font size=-1>></font></blockquote>
</html>

--------------B03E77248C6D228C54B01E8F--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 17 16:40:14 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10089
	for <ipfix-archive@lists.ietf.org>; Tue, 17 Jun 2003 16:40:14 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19SMrP-0001iu-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 17 Jun 2003 15:15:19 -0500
Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19SMrO-0001ip-00
	for ipfix@net.doit.wisc.edu; Tue, 17 Jun 2003 15:15:18 -0500
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28])
	by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5HKF8m11735;
	Tue, 17 Jun 2003 13:15:09 -0700 (PDT)
Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <NALGTGFB>; Tue, 17 Jun 2003 13:14:23 -0700
Message-ID: <0A11633F61BD9F40B43ABCC694004F930218EF9C@zsc3c026.us.nortel.com>
From: "Reinaldo Penno" <rpenno@nortelnetworks.com>
To: "'Ganesh Sadasivan'" <gsadasiv@cisco.com>
Cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] Exporting Control Information
Date: Tue, 17 Jun 2003 13:14:24 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3350D.0B3AC034"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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_01C3350D.0B3AC034
Content-Type: text/plain;
	charset="iso-8859-1"

okay. fair enough.

-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] 
Sent: Tuesday, June 17, 2003 4:12 PM
To: Penno, Reinaldo [BL60:SB20:EXCH]
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Exporting Control Information


  

Reinaldo Penno wrote: 


  

How about we simplify even more? IMO we could do away with the "reaches". We
just say that it has to be reliable and one of the methods is using a
reliable transport. If someone has a different method but it is also
reliable then it is okay. 


   For the reasons 1. and 2., the export of the control information 
   SHOULD be done reliably.

I initially wrote this sentence before sending the e-mail. But this sentence
is 
partial in the sense that it does not talk about the receiver getting
information 
reliably. So is it not prone to mis-interpretation? 

-ganesh 



   One way to achieve this would be  to send the control 
   information over a reliable transport. 

> -----Original Message----- 
> From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com
<mailto:gsadasiv@cisco.com> ] 
> Sent: Tuesday, June 17, 2003 3:45 PM 
> To: Penno, Reinaldo [BL60:SB20:EXCH] 
> Cc: ipfix@net.doit.wisc.edu 
> Subject: Re: [ipfix] Exporting Control Information 
> 
> 
> Hi Reinaldo, 
> 
>    I agree that the statements are fuzzy. How about this one? 
> 
>   For the reasons 1. and 2., the export of the control information 
>   SHOULD be done such that the it reaches the collector reliably. 
>   One way to achieve this would be  to send the control 
>   information over a reliable transport. 
> 
> Thanks 
> Ganesh 
> 
> Reinaldo Penno wrote: 
> 
> > Hello Ganesh, 
> > 
> > I guess everything looks okay except number 3...Some comments 
> > 
> > You say that is it preferred that the export de done over a 
> reliable 
> > connection. Do you mean IPfix connection? If it the 
> "preferred" method 
> > I guess a SHOULD would be more appropriated. 
> > 
> > Using terms like "partially reliable" could be opening a can of 
> > worms...What is a partially reliable transport? And what 
> you mean that 
> > the network is reliable? 
> > 
> > Anyway, my overall suggestion is to rewrite number 3 to 
> make it less 
> > ambiguous and open to interpretation. 
> > 
> > regards, 
> > 
> > Reinaldo 
> > 
> > >      3. For the reasons 1. and 2. it is preferred that 
> the export of 
> > >         Control Information be done over a reliable 
> connection. This 
> > > MAY 
> > > 
> > >         be done through a reliable transport or a 
> partially reliable 
> > >         transport when the underlying network is reliable. 
> > 
> > ----- Original Message ----- 
> > From: "Ganesh Sadasivan" <gsadasiv@cisco.com> 
> > To: <ipfix@net.doit.wisc.edu> 
> > Sent: Monday, June 16, 2003 3:35 PM 
> > Subject: [ipfix] Exporting Control Information 
> > 
> > > Hi, 
> > > 
> > >    The following text describes the architecture for 
> exporting control 
> > >    information. The protocol should have it own section 
> on this topic. 
> > >    Please let me know your thoughts on the paragraphs below. 
> > > 
> > > Exporting Control Information 
> > > 
> > >    The Control Information is used by the collector to : 
> > >    - decode and interpret flow records. 
> > >    - understand the exporter state. 
> > > 
> > >    As such sending control information from exporter in a 
> timely and 
> > >    reliable manner is critical to the proper 
> functionality of the IPFIX 
> > >    collector. The following approaches MAY be taken for 
> the export of 
> > >    control information. 
> > > 
> > >      1. Send all the control information pertaining to 
> flow records 
> > >         prior to sending the flow records themselves. 
> This includes any 
> > >         incremental changes that happens to the 
> definition of the flow 
> > >         records. 
> > > 
> > >      2. Notify on a near real time basis the state of the 
> exporter to 
> > >         the collector. This includes all the changes like a 
> > >         configuration change that affects the flow 
> behavior, changes to 
> > >         exporter resources that affects export rates, etc 
> that which 
> > > the 
> > > 
> > >         collector needs to be aware of. 
> > > 
> > >      3. For the reasons 1. and 2. it is preferred that 
> the export of 
> > >         Control Information be done over a reliable 
> connection. This 
> > > MAY 
> > > 
> > >         be done through a reliable transport or a 
> partially reliable 
> > >         transport when the underlying network is reliable. 
> > > 
> > > Thanks 
> > > Ganesh 
> > > 
> > > 
> > > 
> > > -- 
> > > Help        mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say 
> "help" in message 
> > body 
> > > Unsubscribe mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say 
> "unsubscribe 
> > > ipfix" in message body 
> > > Archive     http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/>  
> > 
> > -- 
> > Help        mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say 
> "help" in message body 
> > Unsubscribe mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say "unsubscribe 
> > ipfix" in message body 
> > Archive     http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/>  
> 
>


------_=_NextPart_001_01C3350D.0B3AC034
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Message</TITLE>

<META content="MSHTML 5.50.4923.2500" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=188181420-17062003>okay. fair enough.</SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Ganesh Sadasivan 
  [mailto:gsadasiv@cisco.com] <BR><B>Sent:</B> Tuesday, June 17, 2003 4:12 
  PM<BR><B>To:</B> Penno, Reinaldo [BL60:SB20:EXCH]<BR><B>Cc:</B> 
  ipfix@net.doit.wisc.edu<BR><B>Subject:</B> Re: [ipfix] Exporting Control 
  Information<BR><BR></FONT></DIV>&nbsp; 
  <P>Reinaldo Penno wrote: 
  <BLOCKQUOTE TYPE="CITE">&nbsp; 
    <P><FONT size=-1>How about we simplify even more? IMO we could do away with 
    the "reaches". We just say that it has to be reliable and one of the methods 
    is using a reliable transport. If someone has a different method but it is 
    also reliable then it is okay.</FONT> 
    <P><FONT size=-1>&nbsp;&nbsp; For the reasons 1. and 2., the export of the 
    control information</FONT> <BR><FONT size=-1>&nbsp;&nbsp; SHOULD be done 
    reliably.</FONT></P></BLOCKQUOTE>I initially wrote this sentence before 
  sending the e-mail. But this sentence is <BR>partial in the sense that it does 
  not talk about the receiver getting information <BR>reliably. So is it not 
  prone to mis-interpretation? 
  <P>-ganesh 
  <BLOCKQUOTE TYPE="CITE"><FONT size=-1></FONT> <BR><FONT size=-1>&nbsp;&nbsp; 
    One way to achieve this would be&nbsp; to send the control</FONT> <BR><FONT 
    size=-1>&nbsp;&nbsp; information over a reliable transport.</FONT> 
    <P><FONT size=-1>&gt; -----Original Message-----</FONT> <BR><FONT 
    size=-1>&gt; From: Ganesh Sadasivan [<A 
    href="mailto:gsadasiv@cisco.com">mailto:gsadasiv@cisco.com</A>]</FONT> 
    <BR><FONT size=-1>&gt; Sent: Tuesday, June 17, 2003 3:45 PM</FONT> <BR><FONT 
    size=-1>&gt; To: Penno, Reinaldo [BL60:SB20:EXCH]</FONT> <BR><FONT 
    size=-1>&gt; Cc: ipfix@net.doit.wisc.edu</FONT> <BR><FONT size=-1>&gt; 
    Subject: Re: [ipfix] Exporting Control Information</FONT> <BR><FONT 
    size=-1>&gt;</FONT> <BR><FONT size=-1>&gt;</FONT> <BR><FONT size=-1>&gt; Hi 
    Reinaldo,</FONT> <BR><FONT size=-1>&gt;</FONT> <BR><FONT 
    size=-1>&gt;&nbsp;&nbsp;&nbsp; I agree that the statements are fuzzy. How 
    about this one?</FONT> <BR><FONT size=-1>&gt;</FONT> <BR><FONT 
    size=-1>&gt;&nbsp;&nbsp; For the reasons 1. and 2., the export of the 
    control information</FONT> <BR><FONT size=-1>&gt;&nbsp;&nbsp; SHOULD be done 
    such that the it reaches the collector reliably.</FONT> <BR><FONT 
    size=-1>&gt;&nbsp;&nbsp; One way to achieve this would be&nbsp; to send the 
    control</FONT> <BR><FONT size=-1>&gt;&nbsp;&nbsp; information over a 
    reliable transport.</FONT> <BR><FONT size=-1>&gt;</FONT> <BR><FONT 
    size=-1>&gt; Thanks</FONT> <BR><FONT size=-1>&gt; Ganesh</FONT> <BR><FONT 
    size=-1>&gt;</FONT> <BR><FONT size=-1>&gt; Reinaldo Penno wrote:</FONT> 
    <BR><FONT size=-1>&gt;</FONT> <BR><FONT size=-1>&gt; &gt; Hello 
    Ganesh,</FONT> <BR><FONT size=-1>&gt; &gt;</FONT> <BR><FONT size=-1>&gt; 
    &gt; I guess everything looks okay except number 3...Some comments</FONT> 
    <BR><FONT size=-1>&gt; &gt;</FONT> <BR><FONT size=-1>&gt; &gt; You say that 
    is it preferred that the export de done over a</FONT> <BR><FONT size=-1>&gt; 
    reliable</FONT> <BR><FONT size=-1>&gt; &gt; connection. Do you mean IPfix 
    connection? If it the</FONT> <BR><FONT size=-1>&gt; "preferred" 
    method</FONT> <BR><FONT size=-1>&gt; &gt; I guess a SHOULD would be more 
    appropriated.</FONT> <BR><FONT size=-1>&gt; &gt;</FONT> <BR><FONT 
    size=-1>&gt; &gt; Using terms like "partially reliable" could be opening a 
    can of</FONT> <BR><FONT size=-1>&gt; &gt; worms...What is a partially 
    reliable transport? And what</FONT> <BR><FONT size=-1>&gt; you mean 
    that</FONT> <BR><FONT size=-1>&gt; &gt; the network is reliable?</FONT> 
    <BR><FONT size=-1>&gt; &gt;</FONT> <BR><FONT size=-1>&gt; &gt; Anyway, my 
    overall suggestion is to rewrite number 3 to</FONT> <BR><FONT size=-1>&gt; 
    make it less</FONT> <BR><FONT size=-1>&gt; &gt; ambiguous and open to 
    interpretation.</FONT> <BR><FONT size=-1>&gt; &gt;</FONT> <BR><FONT 
    size=-1>&gt; &gt; regards,</FONT> <BR><FONT size=-1>&gt; &gt;</FONT> 
    <BR><FONT size=-1>&gt; &gt; Reinaldo</FONT> <BR><FONT size=-1>&gt; 
    &gt;</FONT> <BR><FONT size=-1>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    3. For the reasons 1. and 2. it is preferred that</FONT> <BR><FONT 
    size=-1>&gt; the export of</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Control Information be 
    done over a reliable</FONT> <BR><FONT size=-1>&gt; connection. This</FONT> 
    <BR><FONT size=-1>&gt; &gt; &gt; MAY</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; be done through a 
    reliable transport or a</FONT> <BR><FONT size=-1>&gt; partially 
    reliable</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transport when the 
    underlying network is reliable.</FONT> <BR><FONT size=-1>&gt; &gt;</FONT> 
    <BR><FONT size=-1>&gt; &gt; ----- Original Message -----</FONT> <BR><FONT 
    size=-1>&gt; &gt; From: "Ganesh Sadasivan" &lt;gsadasiv@cisco.com&gt;</FONT> 
    <BR><FONT size=-1>&gt; &gt; To: &lt;ipfix@net.doit.wisc.edu&gt;</FONT> 
    <BR><FONT size=-1>&gt; &gt; Sent: Monday, June 16, 2003 3:35 PM</FONT> 
    <BR><FONT size=-1>&gt; &gt; Subject: [ipfix] Exporting Control 
    Information</FONT> <BR><FONT size=-1>&gt; &gt;</FONT> <BR><FONT size=-1>&gt; 
    &gt; &gt; Hi,</FONT> <BR><FONT size=-1>&gt; &gt; &gt;</FONT> <BR><FONT 
    size=-1>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; The following text describes the 
    architecture for</FONT> <BR><FONT size=-1>&gt; exporting control</FONT> 
    <BR><FONT size=-1>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; information. The protocol 
    should have it own section</FONT> <BR><FONT size=-1>&gt; on this 
    topic.</FONT> <BR><FONT size=-1>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; Please let 
    me know your thoughts on the paragraphs below.</FONT> <BR><FONT size=-1>&gt; 
    &gt; &gt;</FONT> <BR><FONT size=-1>&gt; &gt; &gt; Exporting Control 
    Information</FONT> <BR><FONT size=-1>&gt; &gt; &gt;</FONT> <BR><FONT 
    size=-1>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; The Control Information is used by 
    the collector to :</FONT> <BR><FONT size=-1>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; 
    - decode and interpret flow records.</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp; - understand the exporter state.</FONT> <BR><FONT 
    size=-1>&gt; &gt; &gt;</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp; As such sending control information from exporter in 
    a</FONT> <BR><FONT size=-1>&gt; timely and</FONT> <BR><FONT size=-1>&gt; 
    &gt; &gt;&nbsp;&nbsp;&nbsp; reliable manner is critical to the proper</FONT> 
    <BR><FONT size=-1>&gt; functionality of the IPFIX</FONT> <BR><FONT 
    size=-1>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; collector. The following approaches 
    MAY be taken for</FONT> <BR><FONT size=-1>&gt; the export of</FONT> 
    <BR><FONT size=-1>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; control 
    information.</FONT> <BR><FONT size=-1>&gt; &gt; &gt;</FONT> <BR><FONT 
    size=-1>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. Send all the control 
    information pertaining to</FONT> <BR><FONT size=-1>&gt; flow records</FONT> 
    <BR><FONT size=-1>&gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; prior to sending the 
    flow records themselves.</FONT> <BR><FONT size=-1>&gt; This includes 
    any</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; incremental changes 
    that happens to the</FONT> <BR><FONT size=-1>&gt; definition of the 
    flow</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; records.</FONT> 
    <BR><FONT size=-1>&gt; &gt; &gt;</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2. Notify on a near real time basis the 
    state of the</FONT> <BR><FONT size=-1>&gt; exporter to</FONT> <BR><FONT 
    size=-1>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the 
    collector. This includes all the changes like a</FONT> <BR><FONT 
    size=-1>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    configuration change that affects the flow</FONT> <BR><FONT size=-1>&gt; 
    behavior, changes to</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exporter resources that 
    affects export rates, etc</FONT> <BR><FONT size=-1>&gt; that which</FONT> 
    <BR><FONT size=-1>&gt; &gt; &gt; the</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; collector needs to be 
    aware of.</FONT> <BR><FONT size=-1>&gt; &gt; &gt;</FONT> <BR><FONT 
    size=-1>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. For the reasons 1. 
    and 2. it is preferred that</FONT> <BR><FONT size=-1>&gt; the export 
    of</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Control Information be 
    done over a reliable</FONT> <BR><FONT size=-1>&gt; connection. This</FONT> 
    <BR><FONT size=-1>&gt; &gt; &gt; MAY</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; be done through a 
    reliable transport or a</FONT> <BR><FONT size=-1>&gt; partially 
    reliable</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transport when the 
    underlying network is reliable.</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;</FONT> <BR><FONT size=-1>&gt; &gt; &gt; Thanks</FONT> <BR><FONT 
    size=-1>&gt; &gt; &gt; Ganesh</FONT> <BR><FONT size=-1>&gt; &gt; &gt;</FONT> 
    <BR><FONT size=-1>&gt; &gt; &gt;</FONT> <BR><FONT size=-1>&gt; &gt; 
    &gt;</FONT> <BR><FONT size=-1>&gt; &gt; &gt; --</FONT> <BR><FONT 
    size=-1>&gt; &gt; &gt; Help&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A 
    href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</A> 
    and say</FONT> <BR><FONT size=-1>&gt; "help" in message</FONT> <BR><FONT 
    size=-1>&gt; &gt; body</FONT> <BR><FONT size=-1>&gt; &gt; &gt; Unsubscribe 
    <A 
    href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</A> 
    and say</FONT> <BR><FONT size=-1>&gt; "unsubscribe</FONT> <BR><FONT 
    size=-1>&gt; &gt; &gt; ipfix" in message body</FONT> <BR><FONT size=-1>&gt; 
    &gt; &gt; Archive&nbsp;&nbsp;&nbsp;&nbsp; <A target=_blank 
    href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</A></FONT> 
    <BR><FONT size=-1>&gt; &gt;</FONT> <BR><FONT size=-1>&gt; &gt; --</FONT> 
    <BR><FONT size=-1>&gt; &gt; Help&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <A 
    href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</A> 
    and say</FONT> <BR><FONT size=-1>&gt; "help" in message body</FONT> 
    <BR><FONT size=-1>&gt; &gt; Unsubscribe <A 
    href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</A> 
    and say "unsubscribe</FONT> <BR><FONT size=-1>&gt; &gt; ipfix" in message 
    body</FONT> <BR><FONT size=-1>&gt; &gt; Archive&nbsp;&nbsp;&nbsp;&nbsp; <A 
    target=_blank 
    href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</A></FONT> 
    <BR><FONT size=-1>&gt;</FONT> <BR><FONT 
size=-1>&gt;</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3350D.0B3AC034--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 17 16:56:26 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11120
	for <ipfix-archive@lists.ietf.org>; Tue, 17 Jun 2003 16:56:26 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19SNHJ-0002co-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 17 Jun 2003 15:42:05 -0500
Received: from web80011.mail.yahoo.com ([66.163.168.141])
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 19SNHH-0002ch-00
	for ipfix@net.doit.wisc.edu; Tue, 17 Jun 2003 15:42:04 -0500
Message-ID: <20030617204201.29671.qmail@web80011.mail.yahoo.com>
Received: from [64.164.9.230] by web80011.mail.yahoo.com via HTTP; Tue, 17 Jun 2003 13:42:01 PDT
Date: Tue, 17 Jun 2003 13:42:01 -0700 (PDT)
From: Peter Ludemann <p_ludemann@yahoo.com>
Subject: RE: [ipfix] Exporting Control Information
To: Reinaldo Penno <rpenno@nortelnetworks.com>,
        "'Ganesh Sadasivan'" <gsadasiv@cisco.com>
Cc: ipfix@net.doit.wisc.edu
In-Reply-To: <0A11633F61BD9F40B43ABCC694004F930218EF98@zsc3c026.us.nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Insufficient: reliable transport does not guarantee reliable
delivery. There must be something like an application-level
"ack" to be fully reliable. (This is also necessary if you
want to guarantee that the control information arrives before
any data.)

- peter

--- Reinaldo Penno <rpenno@nortelnetworks.com> wrote:
> How about we simplify even more? IMO we could do away with
> the "reaches". We
> just say that it has to be reliable and one of the methods
> is using a
> reliable transport. If someone has a different method but
> it is also
> reliable then it is okay.
> 
>    For the reasons 1. and 2., the export of the control
> information
>    SHOULD be done reliably.
>    One way to achieve this would be  to send the control
>    information over a reliable transport.
> 
> > -----Original Message-----
> > From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] 
> > Sent: Tuesday, June 17, 2003 3:45 PM
> > To: Penno, Reinaldo [BL60:SB20:EXCH]
> > Cc: ipfix@net.doit.wisc.edu
> > Subject: Re: [ipfix] Exporting Control Information
> > 
> > 
> > Hi Reinaldo,
> > 
> >    I agree that the statements are fuzzy. How about this
> one?
> > 
> >   For the reasons 1. and 2., the export of the control
> information
> >   SHOULD be done such that the it reaches the collector
> reliably.
> >   One way to achieve this would be  to send the control
> >   information over a reliable transport.
> > 
> > Thanks
> > Ganesh
> > 
> > Reinaldo Penno wrote:
> > 
> > > Hello Ganesh,
> > >
> > > I guess everything looks okay except number 3...Some
> comments
> > >
> > > You say that is it preferred that the export de done
> over a 
> > reliable 
> > > connection. Do you mean IPfix connection? If it the 
> > "preferred" method 
> > > I guess a SHOULD would be more appropriated.
> > >
> > > Using terms like "partially reliable" could be opening
> a can of 
> > > worms...What is a partially reliable transport? And
> what 
> > you mean that 
> > > the network is reliable?
> > >
> > > Anyway, my overall suggestion is to rewrite number 3 to
> 
> > make it less 
> > > ambiguous and open to interpretation.
> > >
> > > regards,
> > >
> > > Reinaldo
> > >
> > > >      3. For the reasons 1. and 2. it is preferred
> that 
> > the export of
> > > >         Control Information be done over a reliable 
> > connection. This 
> > > > MAY
> > > >
> > > >         be done through a reliable transport or a 
> > partially reliable
> > > >         transport when the underlying network is
> reliable.
> > >
> > > ----- Original Message -----
> > > From: "Ganesh Sadasivan" <gsadasiv@cisco.com>
> > > To: <ipfix@net.doit.wisc.edu>
> > > Sent: Monday, June 16, 2003 3:35 PM
> > > Subject: [ipfix] Exporting Control Information
> > >
> > > > Hi,
> > > >
> > > >    The following text describes the architecture for 
> > exporting control
> > > >    information. The protocol should have it own
> section 
> > on this topic.
> > > >    Please let me know your thoughts on the paragraphs
> below.
> > > >
> > > > Exporting Control Information
> > > >
> > > >    The Control Information is used by the collector
> to :
> > > >    - decode and interpret flow records.
> > > >    - understand the exporter state.
> > > >
> > > >    As such sending control information from exporter
> in a 
> > timely and
> > > >    reliable manner is critical to the proper 
> > functionality of the IPFIX
> > > >    collector. The following approaches MAY be taken
> for 
> > the export of
> > > >    control information.
> > > >
> > > >      1. Send all the control information pertaining
> to 
> > flow records
> > > >         prior to sending the flow records themselves.
> 
> > This includes any
> > > >         incremental changes that happens to the 
> > definition of the flow
> > > >         records.
> > > >
> > > >      2. Notify on a near real time basis the state of
> the 
> > exporter to
> > > >         the collector. This includes all the changes
> like a
> > > >         configuration change that affects the flow 
> > behavior, changes to
> > > >         exporter resources that affects export rates,
> etc 
> > that which 
> > > > the
> > > >
> > > >         collector needs to be aware of.
> > > >
> > > >      3. For the reasons 1. and 2. it is preferred
> that 
> > the export of
> > > >         Control Information be done over a reliable 
> > connection. This 
> > > > MAY
> > > >
> > > >         be done through a reliable transport or a 
> > partially reliable
> > > >         transport when the underlying network is
> reliable.
> > > >
> > > > 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 Jun 19 11:06:24 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23826
	for <ipfix-archive@lists.ietf.org>; Thu, 19 Jun 2003 11:06:23 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19T0f4-0004BA-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 19 Jun 2003 09:45:14 -0500
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 19T0f3-0004B4-00
	for ipfix@net.doit.wisc.edu; Thu, 19 Jun 2003 09:45:14 -0500
Received: from cisco.com (rtp-vpn2-135.cisco.com [10.82.240.135])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h5JEjBp26405;
	Thu, 19 Jun 2003 16:45:11 +0200 (CEST)
Message-ID: <3EF1CC76.3030801@cisco.com>
Date: Thu, 19 Jun 2003 16:45:10 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ipfix <ipfix@net.doit.wisc.edu>
Subject: [ipfix] draft-ietf-ipfix-protocol-00.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Dear all,

The draft draft-ietf-ipfix-protocol-00.txt just been posted as an 
Internet Draft.
You should receive the annoucement within a few days. I'm sending this 
note beforehand as I won't be available after the announcement appears 
on the mailing list.

This is what has been done by the editors team so far.
1. Some parts of draft-claise-netflow-version9-02.txt have been copied over.
    Obviously, all references to NetFlow/Cisco have been removed.
2. Terminology harmonization.
    The terminology sections from the IPFIX requirements and from 
draft-claise-netflow-version9-02.txt have been copied over.
    When needed, the definitions have been slightly modified.
    The entire draft has been updated according to this new terminology 
section.
    Note: we still need a terminology harmonization with the 
architecture model
3. We updated the table of content, with we think was important to cover.
    Note that some sections are still empty
4. Some text about SCTP has been added
5. Some text (but not polished) has been added for the variable data types
6. A section with the list of open issues has been created
7. A section with the list of open actions has been created

All comments are welcome.
   
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 Jun 19 11:49:39 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26706
	for <ipfix-archive@lists.ietf.org>; Thu, 19 Jun 2003 11:49:39 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19T1Nd-0005R5-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 19 Jun 2003 10:31:17 -0500
Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19T1Nc-0005Qz-00
	for ipfix@net.doit.wisc.edu; Thu, 19 Jun 2003 10:31:16 -0500
Date: Thu, 19 Jun 2003 10:31:16 -0500
From: Dave Plonka <plonka@doit.wisc.edu>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] updated drafts and links
Message-ID: <20030619103116.B10035@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
X-Organization: University of Wisconsin-Madison, DoIT Network Services
X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL)
X-URL: http://net.doit.wisc.edu/~plonka/
X-VMS-Error: %SYSTEM-F-EXPGFLQUOTA, exceeded pagefile quota
X-Shakespearean-Insult: Thou qualling bat-fowling puttock
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


IPFIXers,

The initial versions of the WG drafts are coming along, and it looks as
though the editors will have come through with the submissions in time
for the deadline.  Thanks!

On the IPFIX site, I have updated the links to those drafts and also
mirrored copies.  Please refer to this section of the site:

   http://ipfix.doit.wisc.edu/#IPFIX_related_Internet_Drafts_an

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  Thu Jun 19 11:57:11 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27044
	for <ipfix-archive@lists.ietf.org>; Thu, 19 Jun 2003 11:57:08 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19T1es-0005rG-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 19 Jun 2003 10:49:06 -0500
Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19T1er-0005rB-00
	for ipfix@net.doit.wisc.edu; Thu, 19 Jun 2003 10:49:05 -0500
Date: Thu, 19 Jun 2003 10:49:05 -0500
From: Dave Plonka <plonka@doit.wisc.edu>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] updated subject-tag aliases for mailing list
Message-ID: <20030619104905.C10035@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
X-Organization: University of Wisconsin-Madison, DoIT Network Services
X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL)
X-URL: http://net.doit.wisc.edu/~plonka/
X-VMS-Error: %SYSTEM-F-EXPGFLQUOTA, exceeded pagefile quota
X-Shakespearean-Insult: Thou qualling bat-fowling puttock
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


IPFIXers,

As we work on the WG Internet Drafts, please continue to use the one
public IPFIX mailing list so that everyone can participate and stay
informed.

However, I've created new aliases for the existing IPFIX mailing list
which will cause the message Subject to be tagged appropriately for
each of those our WG Internet Draft efforts: [ipfix-protocol],
[ipfix-reqs], [ipfix-arch], [ipfix-info], and [ipfix-as].

Hopefully those names are self-explanatory as the match the names of
the corresponding WG draft. ("-as" is 'a'pplicability 's'tatement.)

Of course, email to "ipfix@net.doit.wisc.edu" will still go to the list
as it has in the past.

The aliases are described here:

   http://ipfix.doit.wisc.edu/#Mailing_List_Aliases_Convention

from which I have quoted below.

Dave

----------------------------------------------------------------------

  Mailing List Aliases, Conventions, and Policies

    There is only one IPFIX mailing list. General messages can be
    posted to the list by directing them to:

       ipfix@net.doit.wisc.edu

    However, because there are multiple efforts to prepare multiple
    documents within the IPFIX WG, there are multiple "entry points"
    which are simply aliases for that same list. The sole purpose of
    these aliases is to automatically tag the message Subject with a
    special prefix (e.g. "[ipfix-reqs]" for "IPFIX requirements"),
    so that the subject is clearer and the messages are able to be
    filtered based on the recipients interests, if the recipient
    wishes to do so.

    The following IPFIX mailing list aliases are available:

     Requirements, draft-ietf-ipfix-reqs:

            ipfix-reqs@net.doit.wisc.edu

     Architecture, draft-ietf-ipfix-arch:

            ipfix-arch@net.doit.wisc.edu

     Information and Data Model, draft-ietf-ipfix-info:

            ipfix-info@net.doit.wisc.edu

     Applicability Statements, draft-ietf-ipfix-as:

            ipfix-as@net.doit.wisc.edu

     Protocol, draft-ietf-ipfix-protocol:

            ipfix-protocol@net.doit.wisc.edu

-- 
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  Thu Jun 19 15:49:37 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15177
	for <ipfix-archive@lists.ietf.org>; Thu, 19 Jun 2003 15:49:36 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19T5EA-0004CV-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 19 Jun 2003 14:37:46 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19T5E9-0004CN-00
	for ipfix-protocol@net.doit.wisc.edu; Thu, 19 Jun 2003 14:37:45 -0500
Received: from cisco.com (171.71.177.237)
  by sj-iport-1.cisco.com with ESMTP; 19 Jun 2003 12:39:35 -0800
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5JJbgIX017607;
	Thu, 19 Jun 2003 12:37:42 -0700 (PDT)
Received: from cisco.com (dhcp-171-71-204-251.cisco.com [171.71.204.251]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA03756; Thu, 19 Jun 2003 12:37:42 -0700 (PDT)
Message-ID: <3EF21106.95CD4047@cisco.com>
Date: Thu, 19 Jun 2003 12:37:42 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ipfix-protocol@net.doit.wisc.edu
CC: Ganesh Sadasivan <gsadasiv@cisco.com>
Subject: [ipfix-protocol] Comments on open issues
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 8bit

Open Issues

     This section covers the open issues, still to be resolved/updated
in
     this draft:

     - The proposal on the table is to send a IPFIX Sync (this would be
     an Options Data Records) message periodically (periodicity is
     configurable), with the following information (aside the standard
     IPFix header)
             * Number of flow records sent (for each template?)
             * Packets and bytes sent (for each template?)
       Question: Per observation domain?

Ganesh- Yes.


       Question: Do we need a specific FlowSet ID?

Ganesh- Yes. So that it may be easily identified by the collector.


     - Template don't need lifetimes with connection oriented protocol.
     We guess this is the consensus from the Working Group.

Ganesh- Agreed. But are we going to talk about an less reliable
transport also?


     - No periodic retransmission of templates is needed, with a
reliable
     transport protocol.

Ganesh- Agreed.But are we going to talk about an less reliable transport
also?


     Remark: the template management will vary with TCP, SCTP, etcâ¦
     Must have both sections updated: transport updated and template
     management sections (BTW, this is the same for the failover
     section).





     - There seems to be a consensus that having a length field in the
     export packet header.
     Related question: what about the count field then in the NetFlow
     version 9 header? But no consensus yet. So no consensus whether the

     current count should simply be replaced by the length or the length

     field be added.

Ganesh- I would say to replace the count by length.


     - Sub-second timestamps

Ganesh-  There should be a base line granularity (upto say 100 msec or
so) which is
the minimal and a fine grained  time which can upto nano or pico- second
level.

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  Fri Jun 20 14:43:26 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26112
	for <ipfix-archive@lists.ietf.org>; Fri, 20 Jun 2003 14:43:26 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19TQO1-0006MF-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 20 Jun 2003 13:13:21 -0500
Received: from mailhost2.auckland.ac.nz ([130.216.1.4])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19TQNz-0006M2-00
	for ipfix@net.doit.wisc.edu; Fri, 20 Jun 2003 13:13:20 -0500
Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61])
	by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h5KIDH8W006671
	for <ipfix@net.doit.wisc.edu>; Sat, 21 Jun 2003 06:13:17 +1200 (NZST)
Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123])
	by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.5-GR)
	with ESMTP id ARH31800;
	Sat, 21 Jun 2003 06:13:17 +1200 (NZST)
Received: (from apache@localhost)
	by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h5KIDGS28227
	for ipfix@net.doit.wisc.edu; Sat, 21 Jun 2003 06:13:16 +1200
X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f
Received: from 66-91-231-73.san.rr.com (66-91-231-73.san.rr.com
	[66.91.231.73]) by hotlava.auckland.ac.nz (Horde) with HTTP for
	<jbro111@hotlava.auckland.ac.nz>; Sat, 21 Jun 2003 06:13:16 +1200
Message-ID: <1056132796.9e75594b5261b@hotlava.auckland.ac.nz>
Date: Sat, 21 Jun 2003 06:13:16 +1200
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] New set of IPFIX drafts
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP:  66.91.231.73
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


Hello all:

All those involved in producing the -00 verisons of the new IPFIX drafts
have been working very hard over the last few weeks.  I'm delighted to
observe that we now have all four of the new drafts submitted, three days
before the Vienna meeting deadline!  Well done, that puts the WG back on
track with its milestones, and makes a good starting point for everyone
interested in IPFIX (i.e. all those on the IPFIX list) to discuss and
develop the drafts.

Now we need an agenda for IPFIX at the Vienna IETF meeting; we're scheduled
for Thursday afternoon of IETF week.  Here's my initial (draft) agenda:

1. Administrivia

2. Report on progress of the Requirements Draft
      (status as at 20 Jun 03: being revised to address IESG comments)

3. New drafts - I suggest a brief overview presentation for each,
   a list of as-yet-unwritten sections and unresolved issues.
   The drafts are
      draft-ietf-ipfix-arch-00.txt
      draft-ietf-ipfix-info-00.txt
      draft-ietf-ipfix-protocol-00.txt
      draft-ietf-ipfix-as-00.txt

4. Review of WG GOals and ilestones

5. Presentation of nFlow by Luca Deri (offered, to be confirmed)

6. Anything else?

Please send any comments/suggestions to ipfix-chairs@net.doit.wisc.edu

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 20 16:42:36 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07383
	for <ipfix-archive@lists.ietf.org>; Fri, 20 Jun 2003 16:42:36 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19TSbA-0002Au-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 20 Jun 2003 15:35:04 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19TSb7-0002AV-00
	for ipfix-reqs@net.doit.wisc.edu; Fri, 20 Jun 2003 15:35:03 -0500
Received: from cisco.com (171.71.177.237)
  by sj-iport-1.cisco.com with ESMTP; 20 Jun 2003 13:36:51 -0800
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5KKYxIX018521
	for <ipfix-reqs@net.doit.wisc.edu>; Fri, 20 Jun 2003 13:34:59 -0700 (PDT)
Received: from cisco.com (sjc-vpn4-608.cisco.com [10.21.82.96]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA06601 for <ipfix-reqs@net.doit.wisc.edu>; Fri, 20 Jun 2003 13:34:59 -0700 (PDT)
Message-ID: <3EF36FF3.3E456371@cisco.com>
Date: Fri, 20 Jun 2003 13:34:59 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ipfix-reqs@net.doit.wisc.edu
Subject: [ipfix-reqs] Flow definition
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

I was comapring the terminology used in requirements against
architecture. The req spec defines flows as:

"A flow is defined as a set of IP packets passing an observation point
in the network during a certain time interval."

The arch. spec just mentions it as "packets" and not "IP packets".

The "IP packets" does not sound really correct if we are talking about
defining flows based on MPLS too. An MPLS packet could encapsulate
a non-IP packet and if one defines a flow based on just labels, then
it beats the above definition.

I have the following proposal:
1.
"A flow is defined as a set of IP packets or a sub-IP encapsulated IP
packets passing
an observation point in the network during a certain time interval."
2.
In the section on MPLS there should be  a statement telling that for
MPLS packets,
the  metering process has to dig into the packet or by some other means
find out if the encapsulated packet is an IP packet.

Any other suggestions?

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  Mon Jun 23 09:27:57 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19758
	for <ipfix-archive@lists.ietf.org>; Mon, 23 Jun 2003 09:27:57 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19UQuk-0001IG-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 23 Jun 2003 07:59:18 -0500
Received: from ctron-dnm.enterasys.com ([12.25.1.120])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19UQuj-0001IB-00
	for ipfix-reqs@net.doit.wisc.edu; Mon, 23 Jun 2003 07:59:17 -0500
Received: (from uucp@localhost)
	by ctron-dnm.enterasys.com (8.8.7/8.8.7) id JAA20363
	for <ipfix-reqs@net.doit.wisc.edu>; Mon, 23 Jun 2003 09:13:05 -0400 (EDT)
Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1)
	id xma020328; Mon, 23 Jun 03 09:12:07 -0400
Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2 with InterScan Messaging Security Suite; Mon, 23 Jun 2003 08:59:29 -0400
Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 23 Jun 2003 08:59:29 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C33987.47E6D4A0"
Subject: RE: [ipfix-reqs] Flow definition
Date: Mon, 23 Jun 2003 08:59:28 -0400
Message-ID: <6D745637A7E0F94DA070743C55CDA9BA603331@NHROCMBX1.ets.enterasys.com>
Thread-Topic: [ipfix-reqs] Flow definition
Thread-Index: AcM3bEkSR3bg6eSOSY+2zaCeYQqlXwCGuZWA
From: "Harrington, David" <dbh@enterasys.com>
To: "Ganesh Sadasivan" <gsadasiv@cisco.com>, <ipfix-reqs@net.doit.wisc.edu>
X-OriginalArrivalTime: 23 Jun 2003 12:59:29.0538 (UTC) FILETIME=[48732620:01C33987]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C33987.47E6D4A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
I don't think MPLS flows are within the the scope of the charter.
=20
dbh

-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Friday, June 20, 2003 4:35 PM
To: ipfix-reqs@net.doit.wisc.edu
Subject: [ipfix-reqs] Flow definition



I was comapring the terminology used in requirements against=20
architecture. The req spec defines flows as:=20

"A flow is defined as a set of IP packets passing an observation point=20
in the network during a certain time interval."=20

The arch. spec just mentions it as "packets" and not "IP packets".=20

The "IP packets" does not sound really correct if we are talking about=20
defining flows based on MPLS too. An MPLS packet could encapsulate=20
a non-IP packet and if one defines a flow based on just labels, then=20
it beats the above definition.=20

I have the following proposal:=20
1.=20
"A flow is defined as a set of IP packets or a sub-IP encapsulated IP=20
packets passing=20
an observation point in the network during a certain time interval."=20
2.=20
In the section on MPLS there should be  a statement telling that for=20
MPLS packets,=20
the  metering process has to dig into the packet or by some other means=20
find out if the encapsulated packet is an IP packet.=20

Any other suggestions?=20

Thanks=20
Ganesh=20

--=20
Help        mailto:majordomo@net.doit.wisc.edu and say "help" 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_01C33987.47E6D4A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>[ipfix-reqs] Flow definition</TITLE>

<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D560475812-23062003><FONT face=3DArial color=3D#0000ff =

size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D560475812-23062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D560475812-23062003><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
don't think MPLS flows are within the the scope of the=20
charter.</FONT></SPAN></DIV>
<DIV><SPAN class=3D560475812-23062003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D560475812-23062003><FONT face=3DArial color=3D#0000ff =

size=3D2>dbh</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Ganesh Sadasivan=20
  [mailto:gsadasiv@cisco.com]<BR><B>Sent:</B> Friday, June 20, 2003 4:35 =

  PM<BR><B>To:</B> ipfix-reqs@net.doit.wisc.edu<BR><B>Subject:</B> =
[ipfix-reqs]=20
  Flow definition<BR><BR></FONT></DIV><!-- Converted from text/plain =
format -->
  <P><FONT size=3D2>I was comapring the terminology used in requirements =

  against</FONT> <BR><FONT size=3D2>architecture. The req spec defines =
flows=20
  as:</FONT> </P>
  <P><FONT size=3D2>"A flow is defined as a set of IP packets passing an =

  observation point</FONT> <BR><FONT size=3D2>in the network during a =
certain time=20
  interval."</FONT> </P>
  <P><FONT size=3D2>The arch. spec just mentions it as "packets" and not =
"IP=20
  packets".</FONT> </P>
  <P><FONT size=3D2>The "IP packets" does not sound really correct if we =
are=20
  talking about</FONT> <BR><FONT size=3D2>defining flows based on MPLS =
too. An=20
  MPLS packet could encapsulate</FONT> <BR><FONT size=3D2>a non-IP =
packet and if=20
  one defines a flow based on just labels, then</FONT> <BR><FONT =
size=3D2>it beats=20
  the above definition.</FONT> </P>
  <P><FONT size=3D2>I have the following proposal:</FONT> <BR><FONT=20
  size=3D2>1.</FONT> <BR><FONT size=3D2>"A flow is defined as a set of =
IP packets or=20
  a sub-IP encapsulated IP</FONT> <BR><FONT size=3D2>packets =
passing</FONT>=20
  <BR><FONT size=3D2>an observation point in the network during a =
certain time=20
  interval."</FONT> <BR><FONT size=3D2>2.</FONT> <BR><FONT size=3D2>In =
the section=20
  on MPLS there should be&nbsp; a statement telling that for</FONT> =
<BR><FONT=20
  size=3D2>MPLS packets,</FONT> <BR><FONT size=3D2>the&nbsp; metering =
process has to=20
  dig into the packet or by some other means</FONT> <BR><FONT =
size=3D2>find out if=20
  the encapsulated packet is an IP packet.</FONT> </P>
  <P><FONT size=3D2>Any other suggestions?</FONT> </P>
  <P><FONT size=3D2>Thanks</FONT> <BR><FONT size=3D2>Ganesh</FONT> </P>
  <P><FONT size=3D2>--</FONT> <BR><FONT=20
  size=3D2>Help&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A=20
  =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A>=20
  and say "help" in message body</FONT> <BR><FONT size=3D2>Unsubscribe =
<A=20
  =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A>=20
  and say</FONT> <BR><FONT size=3D2>"unsubscribe ipfix" in message =
body</FONT>=20
  <BR><FONT size=3D2>Archive&nbsp;&nbsp;&nbsp;&nbsp; <A=20
  =
href=3D"http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/a=
rchive/</A></FONT>=20
  </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C33987.47E6D4A0--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 23 13:18:50 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29626
	for <ipfix-archive@lists.ietf.org>; Mon, 23 Jun 2003 13:18:49 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19UUlf-0003B1-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 23 Jun 2003 12:06:11 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19UUle-0003At-00
	for ipfix-reqs@net.doit.wisc.edu; Mon, 23 Jun 2003 12:06:10 -0500
Received: from cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 23 Jun 2003 10:05:11 -0800
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5NH67gE004537;
	Mon, 23 Jun 2003 10:06:08 -0700 (PDT)
Received: from cisco.com (dhcp-171-71-204-251.cisco.com [171.71.204.251]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA09601; Mon, 23 Jun 2003 10:06:07 -0700 (PDT)
Message-ID: <3EF7337F.9321FD8C@cisco.com>
Date: Mon, 23 Jun 2003 10:06:07 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Harrington, David" <dbh@enterasys.com>
CC: ipfix-reqs@net.doit.wisc.edu
Subject: Re: [ipfix-reqs] Flow definition
References: <6D745637A7E0F94DA070743C55CDA9BA603331@NHROCMBX1.ets.enterasys.com>
Content-Type: multipart/alternative;
 boundary="------------1521544B58E699F66E8FF71F"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


--------------1521544B58E699F66E8FF71F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Thanks David. I re-read the charter & agree that the charter does
not mention about MPLS flows. But the question is if flow collection is
done on MPLS encapsulated IP packet ? If so should we not explicitly
include them in the flow definition.

-Ganesh

"Harrington, David" wrote:

>  Hi,I don't think MPLS flows are within the the scope of the
> charter.dbh
>
>      -----Original Message-----
>      From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
>      Sent: Friday, June 20, 2003 4:35 PM
>      To: ipfix-reqs@net.doit.wisc.edu
>      Subject: [ipfix-reqs] Flow definition
>
>
>      I was comapring the terminology used in requirements against
>
>      architecture. The req spec defines flows as:
>
>      "A flow is defined as a set of IP packets passing an
>      observation point
>      in the network during a certain time interval."
>
>      The arch. spec just mentions it as "packets" and not "IP
>      packets".
>
>      The "IP packets" does not sound really correct if we are
>      talking about
>      defining flows based on MPLS too. An MPLS packet could
>      encapsulate
>      a non-IP packet and if one defines a flow based on just
>      labels, then
>      it beats the above definition.
>
>      I have the following proposal:
>      1.
>      "A flow is defined as a set of IP packets or a sub-IP
>      encapsulated IP
>      packets passing
>      an observation point in the network during a certain time
>      interval."
>      2.
>      In the section on MPLS there should be  a statement telling
>      that for
>      MPLS packets,
>      the  metering process has to dig into the packet or by some
>      other means
>      find out if the encapsulated packet is an IP packet.
>
>      Any other suggestions?
>
>      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/
>

--------------1521544B58E699F66E8FF71F
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Thanks David. I re-read the charter &amp; agree that the charter does
<br>not mention about MPLS flows. But the question is if flow collection
is
<br>done on MPLS encapsulated IP packet ? If so should we not explicitly
<br>include them in the flow definition.
<p>-Ganesh
<p>"Harrington, David" wrote:
<blockquote TYPE=CITE>&nbsp;<span class=560475812-23062003><font face="Arial"><font color="#0000FF"><font size=-1>Hi,</font></font></font></span><span class=560475812-23062003></span><span class=560475812-23062003><font face="Arial"><font color="#0000FF"><font size=-1>I
don't think MPLS flows are within the the scope of the charter.</font></font></font></span><span class=560475812-23062003></span><span class=560475812-23062003><font face="Arial"><font color="#0000FF"><font size=-1>dbh</font></font></font></span>
<blockquote dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Ganesh Sadasivan [<A HREF="mailto:gsadasiv@cisco.com">mailto:gsadasiv@cisco.com</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Friday, June 20, 2003
4:35 PM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> ipfix-reqs@net.doit.wisc.edu</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> [ipfix-reqs] Flow
definition</font></font>
<br>&nbsp;</div>
<!-- Converted from text/plain format -->
<p><font size=-1>I was comapring the terminology used in requirements against</font>
<br><font size=-1>architecture. The req spec defines flows as:</font>
<p><font size=-1>"A flow is defined as a set of IP packets passing an observation
point</font>
<br><font size=-1>in the network during a certain time interval."</font>
<p><font size=-1>The arch. spec just mentions it as "packets" and not "IP
packets".</font>
<p><font size=-1>The "IP packets" does not sound really correct if we are
talking about</font>
<br><font size=-1>defining flows based on MPLS too. An MPLS packet could
encapsulate</font>
<br><font size=-1>a non-IP packet and if one defines a flow based on just
labels, then</font>
<br><font size=-1>it beats the above definition.</font>
<p><font size=-1>I have the following proposal:</font>
<br><font size=-1>1.</font>
<br><font size=-1>"A flow is defined as a set of IP packets or a sub-IP
encapsulated IP</font>
<br><font size=-1>packets passing</font>
<br><font size=-1>an observation point in the network during a certain
time interval."</font>
<br><font size=-1>2.</font>
<br><font size=-1>In the section on MPLS there should be&nbsp; a statement
telling that for</font>
<br><font size=-1>MPLS packets,</font>
<br><font size=-1>the&nbsp; metering process has to dig into the packet
or by some other means</font>
<br><font size=-1>find out if the encapsulated packet is an IP packet.</font>
<p><font size=-1>Any other suggestions?</font>
<p><font size=-1>Thanks</font>
<br><font size=-1>Ganesh</font>
<p><font size=-1>--</font>
<br><font size=-1>Help&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a>
and say "help" in message body</font>
<br><font size=-1>Unsubscribe <a href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a>
and say</font>
<br><font size=-1>"unsubscribe ipfix" in message body</font>
<br><font size=-1>Archive&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a></font></blockquote>
</blockquote>
</html>

--------------1521544B58E699F66E8FF71F--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 23 18:56:22 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14388
	for <ipfix-archive@lists.ietf.org>; Mon, 23 Jun 2003 18:56:22 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19UZuk-0006la-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 23 Jun 2003 17:35:54 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19UZuj-0006lT-00
	for ipfix-reqs@net.doit.wisc.edu; Mon, 23 Jun 2003 17:35:53 -0500
Received: from cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 23 Jun 2003 15:39:00 -0800
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5NMZoGe029364
	for <ipfix-reqs@net.doit.wisc.edu>; Mon, 23 Jun 2003 15:35:51 -0700 (PDT)
Received: from cisco.com (dhcp-171-71-204-251.cisco.com [171.71.204.251]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA12971 for <ipfix-reqs@net.doit.wisc.edu>; Mon, 23 Jun 2003 15:35:50 -0700 (PDT)
Message-ID: <3EF780C5.C2062210@cisco.com>
Date: Mon, 23 Jun 2003 15:35:50 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ipfix-reqs@net.doit.wisc.edu
Subject: [ipfix-reqs] Questions on terminology in req spec
References: <6D745637A7E0F94DA070743C55CDA9BA603331@NHROCMBX1.ets.enterasys.com> <3EF7337F.9321FD8C@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


Looks like there no definition for an IPFIX device in the reqs spec.
Shouldn't there be ?

Should there be definition for "Collector"  which is the receiving IPFIX

device in addition to "Collecting Process".

"Collector
The device which hosts one or more collecting processes."

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  Tue Jun 24 04:26:24 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07083
	for <ipfix-archive@lists.ietf.org>; Tue, 24 Jun 2003 04:26:24 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Uijf-0002gn-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 24 Jun 2003 03:01:03 -0500
Received: from babar.switch.ch ([130.59.4.85])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Uije-0002gc-00
	for ipfix-reqs@net.doit.wisc.edu; Tue, 24 Jun 2003 03:01:02 -0500
Received: from babar.switch.ch (localhost [IPv6:::1])
	by babar.switch.ch (8.12.9+Sun/8.12.2) with ESMTP id h5O80aEI017963;
	Tue, 24 Jun 2003 10:00:37 +0200 (CEST)
Received: (from leinen@localhost)
	by babar.switch.ch (8.12.9+Sun/8.12.2/Submit) id h5O80Z6t017962;
	Tue, 24 Jun 2003 10:00:35 +0200 (CEST)
X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f
To: Ganesh Sadasivan <gsadasiv@cisco.com>
Cc: "Harrington, David" <dbh@enterasys.com>, ipfix-reqs@net.doit.wisc.edu
Subject: Re: [ipfix-reqs] Flow definition
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
   7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
From: Simon Leinen <simon@limmat.switch.ch>
In-Reply-To: <3EF7337F.9321FD8C@cisco.com> (Ganesh Sadasivan's message of
 "Mon, 23 Jun 2003 10:06:07 -0700")
References: <6D745637A7E0F94DA070743C55CDA9BA603331@NHROCMBX1.ets.enterasys.com>
	<3EF7337F.9321FD8C@cisco.com>
Date: Tue, 24 Jun 2003 10:00:34 +0200
Message-ID: <aawufbvra5.fsf@limmat.switch.ch>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2.95 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Ganesh Sadasivan writes:
> Thanks David. I re-read the charter & agree that the charter does
> not mention about MPLS flows. But the question is if flow collection
> is done on MPLS encapsulated IP packet ? If so should we not
> explicitly include them in the flow definition.

I would say no, we shouldn't.
-- 
Simon.

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 24 22:04:14 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02791
	for <ipfix-archive@lists.ietf.org>; Tue, 24 Jun 2003 22:04:14 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19UzVD-0001aq-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 24 Jun 2003 20:55:15 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19UzVC-0001ai-00
	for ipfix@net.doit.wisc.edu; Tue, 24 Jun 2003 20:55:14 -0500
Received: from cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 24 Jun 2003 18:54:34 -0800
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5P1tAgE009113;
	Tue, 24 Jun 2003 18:55:11 -0700 (PDT)
Received: from cisco.com (dhcp-171-71-204-157.cisco.com [171.71.204.157]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA14736; Tue, 24 Jun 2003 18:55:10 -0700 (PDT)
Message-ID: <3EF900FE.53E52A00@cisco.com>
Date: Tue, 24 Jun 2003 18:55:10 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Nevil Brownlee <n.brownlee@auckland.ac.nz>
CC: Simon Leinen <simon@limmat.switch.ch>,
        "Harrington,David" <dbh@enterasys.com>, ipfix@net.doit.wisc.edu
Subject: [ipfix] Re: [ipfix-reqs] Flow definition
References: <6D745637A7E0F94DA070743C55CDA9BA603331@NHROCMBX1.ets.enterasys.com>
		<3EF7337F.9321FD8C@cisco.com> <aawufbvra5.fsf@limmat.switch.ch> <1056496459.e98a9a3bd377b@hotlava.auckland.ac.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Hi Nevil,

Nevil Brownlee wrote:

> Hi Simon:
>
> > Ganesh Sadasivan writes:
> > > Thanks David. I re-read the charter & agree that the charter does
> > > not mention about MPLS flows. But the question is if flow collection
> > > is done on MPLS encapsulated IP packet ? If so should we not
> > > explicitly include them in the flow definition.
> >
> > I would say no, we shouldn't.
>
> I've been working with Ganesh on editing the Architecture Draft.
> Seems to me that this is an issue which needs more discussion.
> Here's my thoughts on it:
>
>  - If a network element (switch or router) understands things
>    like MPLS, it makes sense to let it use that understanding
>    in creating flows.
>

Agreed.

>
>  - On the other hand, we have to define a 'base specification,'
>    i.e. what's the minimum set of packet attributes an IPFIX
>    exporter MUST support if it claims to be IPFIX-conformant?

The requirement spec talks about the minimal requirements.
But as you say, we need to have better definition in terms of
what gets supported in the case of GRE, IP-in-IP etc where
there could be the same fields (like IP address) in the multiple
encapsulated layers. This IMHO can go into the information
model.

>
>
>  - It's very difficult to decide where to draw the line on this.
>    MPLS is clear enough, but how about other encapsulations,
>    e.g. IP-in-IP, GRE, etc.?  Application information, e.g. in
>    RTP header fields [RFC1889], raises even more questions.
>

I am copying your suggested definition of flow which looks
fine to me:

"A 'flow' is a set of IP packets, or encapsulated
IP 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. "

>
> How about the following as a minimal definition for the header
> fields which can define a flow?  (This is one of three list items
> in the current Architecture Draft).

>
>
>  * One or more header fields of the actual packet, e.g. destination
>    IP address, or one of the fields in the packet's encapsulation
>    header, e.g. label for MPLS, tunnel end-points for IP-in-IP, etc.

Agreed.

>
>
> The IPFIX Information Model could specify encapsulation-header-based
> attributes as they seem neccessary and/or useful ...
>
> Also, another Architecture issue, the Architecture Draft (in its
> original versions) refers at various points to flow 'keys' and
> 'fields.'

While discussing the flow defintion sometime back we agreed upon to
use  the term flow 'keys' . Mainly because it was understood by all
folks who were participating in that discussion. I am ok using 'attributes'
or 'keys' but not both:)

>

> Although it's sensible to talk about 'fields' in the
> exported flow records, I feel it would be more sensible to use the
> term 'attributes' to refer to things used in defining flows, in all
> the IPFIX drafts.  That would mean that IPFIX was using the term
> 'flow attributes' in the same way as is done in RFCs 2720-2724 (RTFM)
> and 2924 (Accounting Attributes).  What do others think about this?
>
> Cheers, Nevil
>
> -----------------------------------------------------------------------
>    Nevil Brownlee                   Director, Technology Development
>    Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
>    FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
>
> -------------------------------------------------
> This mail sent through University of Auckland
> http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 24 22:33:00 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03551
	for <ipfix-archive@lists.ietf.org>; Tue, 24 Jun 2003 22:32:59 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Uzxq-0002N7-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 24 Jun 2003 21:24:50 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Uzxn-0002Mw-00
	for ipfix@net.doit.wisc.edu; Tue, 24 Jun 2003 21:24:47 -0500
Received: from cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 24 Jun 2003 19:27:57 -0800
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5P2OhMO022322
	for <ipfix@net.doit.wisc.edu>; Tue, 24 Jun 2003 19:24:45 -0700 (PDT)
Received: from cisco.com (dhcp-171-71-204-157.cisco.com [171.71.204.157]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id TAA14822 for <ipfix@net.doit.wisc.edu>; Tue, 24 Jun 2003 19:24:43 -0700 (PDT)
Message-ID: <3EF907EB.7C2B88A@cisco.com>
Date: Tue, 24 Jun 2003 19:24:43 -0700
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [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] Arch spec changes for 01
References: <6D745637A7E0F94DA070743C55CDA9BA603331@NHROCMBX1.ets.enterasys.com>
			<3EF7337F.9321FD8C@cisco.com> <aawufbvra5.fsf@limmat.switch.ch> <1056496459.e98a9a3bd377b@hotlava.auckland.ac.nz> <3EF900FE.53E52A00@cisco.com>
Content-Type: multipart/alternative;
 boundary="------------7691277AB76E54F8F2B721A9"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


--------------7691277AB76E54F8F2B721A9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

    I added text to some of the unfilled section in the arch spec. Please
    comment .

Encoding Control Information

   The following rules provide guidelines to be followed while encoding
   the control information.

     - Per-flow control information SHOULD be encoded such that it can
       capture the structure and semantics of the corresponding flow
       data for each of the flows exported by the IPFIX device.
     - Configuration control information SHOULD be encoded such that it
       can capture the structure and semantics of the corresponding
       configuration data. The configuration data which is also control
       information, SHOULD carry additional information on the boundary
       within which the configuration takes effect. For example, sampling
       using the same sampling algorithm, say 1 in 100 packets is
       configured on 2 observation points O1 and O2. The configuration
       in this case MAY be encoded as <ID, boundary (O1,O2), sampling
       algorithm, interval (1 in 100)> where ID uniquely identifies this
       configuration.
     - There SHOULD be provisions to encode fixed length and variable
       length fields
     - Should we mention anything about the order in which fields are
       encoded, i.e. network order/host order?  [Nevil's suggestion: all
       fields MUST be encoded in network byte order]

 Encoding Flow Data Information

   The following rules provide guidelines to be followed while encoding
   the flow data information.

     - A flow data record SHOULD contain enough information so that the
       collecting process can identify the corresponding <Per-flow
       control information, Configuration control information>.


IPFIX Specific DoS attack

   There is a specific attack on the IPFIX portion of the IPFIX device
   or Collector.
     - The attacker could pound the  Collector with spoofed IPFIX export
       packets. One way to solve this problem is to periodically
       synchronize the sequence numbers of the flow records between
       exporting process and the collecting process.
     - The attacker could provide false reports to the IPFIX device by
       sending spoofed control packets.


   The problems mentioned above can be solved to a large extent if the
   control packets are encrypted both ways.



Thanks
Ganesh

--------------7691277AB76E54F8F2B721A9
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<br>&nbsp;
<br>&nbsp;&nbsp;&nbsp; I added text to some of the unfilled section in
the arch spec. Please
<br>&nbsp;&nbsp;&nbsp; comment .
<p><b>Encoding Control Information</b>
<p>&nbsp;&nbsp; The following rules provide guidelines to be followed while
encoding
<br>&nbsp;&nbsp; the control information.
<p>&nbsp;&nbsp;&nbsp;&nbsp; - Per-flow control information SHOULD be encoded
such that it can
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; capture the structure and semantics
of the corresponding flow
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; data for each of the flows exported
by the IPFIX device.
<br>&nbsp;&nbsp;&nbsp;&nbsp; - Configuration control information SHOULD
be encoded such that it
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; can capture the structure and
semantics of the corresponding
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; configuration data. The configuration
data which is also control
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; information, SHOULD carry additional
information on the boundary
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; within which the configuration
takes effect. For example, sampling
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; using the same sampling algorithm,
say 1 in 100 packets is
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; configured on 2 observation points
O1 and O2. The configuration
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in this case MAY be encoded as
&lt;ID, boundary (O1,O2), sampling
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; algorithm, interval (1 in 100)>
where ID uniquely identifies this
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; configuration.
<br>&nbsp;&nbsp;&nbsp;&nbsp; - There SHOULD be provisions to encode fixed
length and variable
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; length fields
<br>&nbsp;&nbsp;&nbsp;&nbsp; - Should we mention anything about the order
in which fields are
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; encoded, i.e. network order/host
order?&nbsp; [Nevil's suggestion: all
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fields MUST be encoded in network
byte order]
<p>&nbsp;<b>Encoding Flow Data Information</b><b></b>
<p>&nbsp;&nbsp; The following rules provide guidelines to be followed while
encoding
<br>&nbsp;&nbsp; the flow data information.
<p>&nbsp;&nbsp;&nbsp;&nbsp; - A flow data record SHOULD contain enough
information so that the
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; collecting process can identify
the corresponding &lt;Per-flow
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; control information, Configuration
control information>.
<br>&nbsp;
<p><b>IPFIX Specific DoS attack</b>
<p>&nbsp;&nbsp; There is a specific attack on the IPFIX portion of the
IPFIX device
<br>&nbsp;&nbsp; or Collector.
<br>&nbsp;&nbsp;&nbsp;&nbsp; - The attacker could pound the&nbsp; Collector
with spoofed IPFIX export
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packets. One way to solve this
problem is to periodically
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; synchronize the sequence numbers
of the flow records between
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exporting process and the collecting
process.
<br>&nbsp;&nbsp;&nbsp;&nbsp; - The attacker could provide false reports
to the IPFIX device by
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sending spoofed control packets.
<br>&nbsp;
<p>&nbsp;&nbsp; The problems mentioned above can be solved to a large extent
if the
<br>&nbsp;&nbsp; control packets are encrypted both ways.
<br>&nbsp;
<br>&nbsp;
<p>Thanks
<br>Ganesh</html>

--------------7691277AB76E54F8F2B721A9--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 24 22:52:01 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02799
	for <ipfix-archive@lists.ietf.org>; Tue, 24 Jun 2003 22:04:14 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Ux0Q-0005J5-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 24 Jun 2003 18:15:18 -0500
Received: from mailhost2.auckland.ac.nz ([130.216.191.4])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Ux0P-0005J0-00
	for ipfix@net.doit.wisc.edu; Tue, 24 Jun 2003 18:15:17 -0500
Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61])
	by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h5ONEL8W014217;
	Wed, 25 Jun 2003 11:14:21 +1200 (NZST)
Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123])
	by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.5-GR)
	with ESMTP id ARK50697;
	Wed, 25 Jun 2003 11:14:20 +1200 (NZST)
Received: (from apache@localhost)
	by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h5ONEJJ19796;
	Wed, 25 Jun 2003 11:14:19 +1200
X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f
Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz
	[130.216.4.167]) by hotlava.auckland.ac.nz (Horde) with HTTP for
	<jbro111@hotlava.auckland.ac.nz>; Wed, 25 Jun 2003 11:14:19 +1200
Message-ID: <1056496459.e98a9a3bd377b@hotlava.auckland.ac.nz>
Date: Wed, 25 Jun 2003 11:14:19 +1200
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
To: Simon Leinen <simon@limmat.switch.ch>
Cc: Ganesh Sadasivan <gsadasiv@cisco.com>,
        "Harrington,David"
	<dbh@enterasys.com>, ipfix@net.doit.wisc.edu
Subject: [ipfix] Re: [ipfix-reqs] Flow definition
References: 	<6D745637A7E0F94DA070743C55CDA9BA603331@NHROCMBX1.ets.enterasys.com>
	<3EF7337F.9321FD8C@cisco.com> <aawufbvra5.fsf@limmat.switch.ch>
In-Reply-To: <aawufbvra5.fsf@limmat.switch.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP:  130.216.4.167
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


Hi Simon:

> Ganesh Sadasivan writes:
> > Thanks David. I re-read the charter & agree that the charter does
> > not mention about MPLS flows. But the question is if flow collection
> > is done on MPLS encapsulated IP packet ? If so should we not
> > explicitly include them in the flow definition.
> 
> I would say no, we shouldn't.

I've been working with Ganesh on editing the Architecture Draft.
Seems to me that this is an issue which needs more discussion.
Here's my thoughts on it:

 - If a network element (switch or router) understands things
   like MPLS, it makes sense to let it use that understanding
   in creating flows.

 - On the other hand, we have to define a 'base specification,'
   i.e. what's the minimum set of packet attributes an IPFIX
   exporter MUST support if it claims to be IPFIX-conformant?

 - It's very difficult to decide where to draw the line on this.
   MPLS is clear enough, but how about other encapsulations,
   e.g. IP-in-IP, GRE, etc.?  Application information, e.g. in
   RTP header fields [RFC1889], raises even more questions.

How about the following as a minimal definition for the header
fields which can define a flow?  (This is one of three list items
in the current Architecture Draft).

 * One or more header fields of the actual packet, e.g. destination 
   IP address, or one of the fields in the packet's encapsulation 
   header, e.g. label for MPLS, tunnel end-points for IP-in-IP, etc.

The IPFIX Information Model could specify encapsulation-header-based 
attributes as they seem neccessary and/or useful ...

Also, another Architecture issue, the Architecture Draft (in its
original versions) refers at various points to flow 'keys' and
'fields.'  Although it's sensible to talk about 'fields' in the
exported flow records, I feel it would be more sensible to use the
term 'attributes' to refer to things used in defining flows, in all
the IPFIX drafts.  That would mean that IPFIX was using the term
'flow attributes' in the same way as is done in RFCs 2720-2724 (RTFM)
and 2924 (Accounting Attributes).  What do others think about this?

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 25 12:08:20 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19156
	for <ipfix-archive@lists.ietf.org>; Wed, 25 Jun 2003 12:08:19 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19VCRR-0001aw-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 25 Jun 2003 10:44:13 -0500
Received: from host60-112.pool8173.interbusiness.it ([81.73.112.60] helo=localhost.localdomain)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19VCRO-0001ag-00
	for ipfix@net.doit.wisc.edu; Wed, 25 Jun 2003 10:44:10 -0500
Received: from ntop.org (athlon [127.0.0.1])
	by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h5PFi6rq023795
	for <ipfix@net.doit.wisc.edu>; Wed, 25 Jun 2003 17:44:07 +0200
Message-ID: <3EF9C346.2050309@ntop.org>
Date: Wed, 25 Jun 2003 17:44:06 +0200
From: Luca Deri <deri@ntop.org>
Organization: ntop.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] nFlow Rewised
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Dear all,
a while ago I have posted a mail about a new flow format named nFlow. 
Based on the comments received by some of you I have updated the flow 
definition and based on NetFlow v9 (this was the main concern). At 
http://www.nflow.org/ you can find the nFlow specs and download a new 
prerelease version of nProbe (a software NetFlow probe I have developed) 
that supports both NetFlow v5/v9 and nFlow, so that you can play with 
nFlow and compare it with NetFlow.

I would very much appreciate to receive you feedback on this work. As 
Nevil pointed out, I hope to convince my management to allow me to show 
up in Vienna to introduce you nFlow and see whether some of the ideas I 
have put on it there can influence the design of IPFIX.

Regards, Luca

-- 
Luca Deri <deri@ntop.org>	http://luca.ntop.org/
Hacker: someone who loves to program and enjoys being
clever about it - Richard Stallman


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 25 22:17:26 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21445
	for <ipfix-archive@lists.ietf.org>; Wed, 25 Jun 2003 22:17:25 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19VLuH-0004Oi-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 25 Jun 2003 20:50:37 -0500
Received: from cms2.etri.re.kr ([129.254.16.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19VLuF-0004OW-00
	for ipfix@net.doit.wisc.edu; Wed, 25 Jun 2003 20:50:36 -0500
Received: by cms2 with Internet Mail Service (5.5.2653.19)
	id <NH3K81Z2>; Thu, 26 Jun 2003 10:50:35 +0900
Message-ID: <A870CB5EE2A3D5118D0C00D0B7A8D8F5022B96B1@cms2>
From: choits@etri.re.kr
To: ipfix@net.doit.wisc.edu
Cc: psam@ops.ietf.org, n.brownlee@auckland.ac.nz, kimch@etri.re.kr,
        tsjeong@etri.re.kr
Subject: [ipfix] Per-packet record proposal
Date: Thu, 26 Jun 2003 10:50:34 +0900
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C33B85.557424F0"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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_01C33B85.557424F0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C33B85.557424F0"


------_=_NextPart_001_01C33B85.557424F0
Content-Type: text/plain;
	charset="euc-kr"

Dear IPFIXers,

We have read through a set of IPFIX drafts and found that it may be useful
to extend the IPFIX information model, metering process, configuration, and
data export as described in the attached draft.  We provided the rationale
of our proposal and necessary extensions in the document in detail.  We
would highly apprciate your time for reading and commenting it.

We submitted this document as an individual submission but it hasn't been
registered in the IETF internet draft registery yet.  Thus, I attached the
document for your easiler reference.  

Sincerely,

Taesang, Changhoon
ETRI


------_=_NextPart_001_01C33B85.557424F0
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Deuc-kr">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Per-packet record proposal</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Dear IPFIXers,</FONT>
</P>

<P><FONT SIZE=3D2>We have read through a set of IPFIX drafts and found =
that it may be useful to extend the IPFIX information model, metering =
process, configuration, and data export as described in the attached =
draft.&nbsp; We provided the rationale of our proposal and necessary =
extensions in the document in detail.&nbsp; We would highly apprciate =
your time for reading and commenting it.</FONT></P>

<P><FONT SIZE=3D2>We submitted this document as an individual =
submission but it hasn't been registered in the IETF internet draft =
registery yet.&nbsp; Thus, I attached the document for your easiler =
reference.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Sincerely,</FONT>
</P>

<P><FONT SIZE=3D2>Taesang, Changhoon</FONT>
<BR><FONT SIZE=3D2>ETRI</FONT>
</P>

<P><FONT FACE=3D"=B1=BC=B8=B2" SIZE=3D2 COLOR=3D"#000000"></FONT>&nbsp;

</BODY>
</HTML>
------_=_NextPart_001_01C33B85.557424F0--

------_=_NextPart_000_01C33B85.557424F0
Content-Type: text/plain;
	name="draft-kim-ipfix-ppr-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-kim-ipfix-ppr-00.txt"
Content-Transfer-Encoding: quoted-printable


Internet Draft                                              Chang H. =
Kim
draft-kim-ipfix-ppr-00.txt                                  Taesang =
Choi
Expires: December 2003                                              =
ETRI
                                                               June =
2003   =20
                                 =20
                                                          =20
                                                      =20
       Supplementing IPFIX Flow Informaion with Per-packet Records


                      <draft-kim-ipfix-ppr-00.txt>
                     =20

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   This document describes extensions required to supplement the IP =
flow
   information export with per-packet records of which generation and
   export are configurable. The extension supports more precise
   application-aware usage accounting, detailed traffic profiling,
   enhanced intrusion and attack detection, etc. Extensions on the=20
   existing information model, the Metering Process, the configuration
   , and the data export protocol are also mentioned.
=20




Kim, et al.            expires - December, 2003             [Page 1]
=0C
Internet Draft            Per-packet Records               June 2003

Table of Contents

   1. Introduction ................................................    =
3
   2. Applicability ...............................................    =
4
     2.1. Usage-based Accounting ..................................    =
4
     2.2. Traffic Profiling .......................................    =
5
     2.3. Attack/Intrusion Detection ..............................    =
5
     2.4. Application Monitoring and Profiling ....................    =
5
   3. Methods for Adopting Per-packet Records......................    =
6
     3.1. Information Model Extension .............................    =
6
     3.1.1. pktArrivalTimeOffset ..................................    =
6
     3.1.1.1. Type ................................................    =
6
     3.1.1.2. Field Id ............................................    =
6
     3.1.1.3. Reference ...........................................    =
6
     3.1.2. pktLen ................................................    =
6
     3.1.2.1. Type ................................................    =
6
     3.1.2.2. Field Id ............................................    =
6
     3.1.3. pktId .................................................    =
7
     3.1.3.1. Type ................................................    =
7
     3.1.3.2. Field Id ............................................    =
7
     3.1.4. pktFlags ..............................................    =
7
     3.1.4.1. Type ................................................    =
7
     3.1.4.2. Field Id ............................................    =
7
     3.1.5. pktTtl ................................................    =
7
     3.1.5.1. Type ................................................    =
7
     3.1.5.2. Field Id ............................................    =
7
     3.1.6. pktFragIndication .....................................    =
7
     3.1.6.1. Type ................................................    =
7
     3.1.6.2. Field Id ............................................    =
7
     3.1.7. tcpFlags ..............................................    =
7
     3.1.7.1. Type ................................................    =
8
     3.1.7.2. Field Id ............................................    =
8
     3.1.8. tcpSeqNumber ..........................................    =
8
     3.1.8.1. Type ................................................    =
8
     3.1.8.2. Field Id ............................................    =
8
     3.1.9. tcpAckNumber ..........................................    =
8
     3.1.9.1. Type ................................................    =
8
     3.1.9.2. Field Id ............................................    =
8
     3.1.10. pktEntirePayload .....................................    =
8
     3.1.10.1. Type ...............................................    =
8
     3.1.10.2. Field Id ...........................................    =
8
     3.1.10.3. Reference ..........................................    =
8
     3.1.11. pktPartialPayload ....................................    =
9
     3.1.11.1. Type ...............................................    =
9
     3.1.11.2. Field Id ...........................................    =
9
     3.1.11.3. Reference ..........................................    =
9
     3.2. Metering Process Extension ..............................    =
9
     3.2.1. Metering Process Functions ............................    =
9
     3.2.2. Selection Criteria for Packet Information Export ......   =
10
     3.2.3. Pattern Specification and Pattern Matching ............   =
10
=20
Kim, et al.            expires - December, 2003             [Page 2]
=0C
Internet Draft            Per-packet Records               June 2003    =

    =20
     3.3. Configuration Extension .................................   =
11
     3.3.1. Configuration Extension for the Metering Process ......   =
11
     3.3.2. Configuration Extension for the Exporting Process .....   =
11
     3.4. Data Export Extension ...................................   =
12
     3.4.1.  Export Layout ........................................   =
12
     3.4.2.  Export Interval ......................................   =
13
     3.5. Collector Extension .....................................   =
13
   4. Security Considerations .....................................   =
13
   5. References ..................................................   =
13


1.  Introduction

   Internet traffic has been dominated by client-server applications=20
   until late 90s. Starting from "Napster", however, various=20
   next-generation applications have been drastically getting popular.
   Peer-to-peer contents sharing programs, network-based games,
   e-commerce tools, and multimedia streaming applications are all
   good examples. Unlike the traditional Internet applications that
   could be easily identified by their port numbers, identifying and=20
   characterizing these sort of unprecedented traffic demand enhanced
   mechanisms beyond port mapping. In the meantime, the amount of =
traffic
   volume generated by such applications began to grow from a =
negligible
   portion to more than half of the total volume, although there exists
   a good deal of variation depending upon time, region, occasion, user
   group, etc.

   Both the recent explosion of the number of unprecedented =
applications
   and the common use of port range allocation give rise to a high=20
   frequency of the overlapped service ports problem. For example,
   users intentionally configure a new application to share a well=20
   known service port, say 80 of HTTP, for an infiltration purpose.
   Overlapped service ports, however, even combined with the flow=20
   concept, preclude ensuring a high degree of application recognition
   correctness. To overcome this limitation, we need to investigate
   the contents of packets to search for each application=A1=AFs=20
   distinctive signature. The signature can be an ASCII string, 
   a binary code, or a combination of them. Using the flow concept=20
   in conjunction with payload inspection, we can obtain synergy =
effect;
   packets that do not contain any distinctive signature can also be
   classified to the application whose signature is found in the=20
   other packets in the same flow. Nevertheless, since the operational
   burden of the payload investigation method is much higher than
   that of the simple port-based one, its use should be limited and=20
   configurable depending on the number and speed of the monitored
   links, available computing resources, and other operational =
constraints.
   Configurability, thus, plays a principal role in the designing
   and implementing process of a recognition system which is capable
   of payload investigation.

Kim, et al.            expires - December, 2003             [Page 3]
=0C
Internet Draft            Per-packet Records               June 2003

   For the sake of traffic profiling, on the other hand, various
   flow statistics are required such as flow duration, flow volume,
   timing, and burstiness. Besides these flow related statistics,
   packet specific statistics information (e.g., packet size
   distribution, packet inter-arrival time, etc.) is also very=20
   useful for per-packet traffic profiling. Supplementing the existing
   IPFIX with per-packet information, thus, can be highly useful for=20
   this purpose.

   In this draft, we propose to add per-packet records supplementing
   IPFIX flow information in order to provide IPFIX applications with
   more detailed and precise information. We address detailed
   applicability and requirements in section 2 for each application.
   Extensions on the existing information model and processes for=20
   satisfying such requirements are provided in section 3.
 =20
2.  Applicability

   IPFIX applicability draft [2] describes critical customer
   applications which may utilize IPFIX data. The applications are
   accounting, peering agreements, traffic engineering, data
   warehousing and mining, and network monitoring. Altough the
   draft mention that the existing IPFIX architecture can support
   all these applications, additional information or mechanisms on
   exporting per-packet records is necessary.=20
   More details on each application field are described below.

2.1.  Usage-based Accounting

   The IPFIX applicability draft states that charging can be based on
   application usage among others. The IPFIX architecture provides=20
   this information based on port numbers. But, as mentioned in
   the introduction, mapping applications and port numbers are no
   longer safe and newer mechanisms, such as signature matching,
   are required for precise application usage accounting.
   Some applications can be identified simply by matching application
   specific signature per packet basis. However, other applications
   require cross-check with internal sub-flows which may occur in
   opposite flow direction or even in another link.
   In the former case, application signature information needs=20
   to be added in the information model. In the latter case, however,
   precise application recognition with signature matching on a
   single link is not possible. Instead, flow record somehow has to
   keep the application signature information and a collector which
   monitors multiple links later correlate results for the accurate
   recognition.  For this purpose, we propose to add a packet record=20
   and keep an application signature in it.  Collector can use them
   later during analysis phase.

Kim, et al.            expires - December, 2003             [Page 4]
=0C
Internet Draft            Per-packet Records               June 2003

2.2.  Traffic Profiling

   For the proper traffic profiling, various statistics are needed
   and many of them are listed in the requirement and applicability
   draft such as flow duration, volume, time and burstiness.
   Besides these flow related statistics, packet specific statistics
   information (e.g., packet size distribution, packet inter-arrival =
time,
   fragement statistics, etc.) is also very important for traffic =
profiling.=20
   IPFIX architecture doesn=A1=AFt take this aspect into consideration. =

   Additional packet related information, thus, needs to be added as=20
   a part of the IPFIX information model if packet related traffic=20
   profiling is required.  Since this information is packet specific =
ones,=20
   flow record is not a good place to add them. We propose a packet=20
   record for the place holder of such information.

2.3.  Attack/Intrusion Detection

   IPFIX architecture allows packet content inspection for=20
   attack/intrusion detection. However, it doesn=A1=AFt define elements =
of=20
   information model for storing such information, metering process=20
   and exporting process. Similar to usage-based accounting case,=20
   virus or worm signature information can be captured in packet =
records=20
   for post-processing by analysis applications.

2.4.  Application Monitoring and Profiling

   IPFIX architecture states that it enables content and service
   providers to view detailed, time-based, and application-based
   usage of a network.  Simple port based accounting per application
   doesn=A1=AFt faithfully measure its usage. Also QoS monitoring per
   application may be a requirement for content and service providers.
   It requires more precise application profiling as the case of=20
   the usage-based accounting.


















Kim, et al.            expires - December, 2003             [Page 5]
=0C
Internet Draft            Per-packet Records               June 2003

3.  Methods for Adopting Per-packet Records

   The following are required extension on the existing IP flow=20
   information export specifications [3][4][5].

3.1.  Information Model Extension

   As specified in section 6 of IPFIX Information Model document [5],
   the existing IPFIX information model allows for extending the set
   of information items. This section, thus, defines new information
   elements for exporting per-packet information.

3.1.1.	pktArrivalTimeOffset

   The offset of the packet's arrival timestamp to the flowCreationTime
   of the flow.

3.1.1.1.  Type

   The pktArrivalTime element is of type ipdr:dateTimeUsec.

3.1.1.2.  Field Id

   The field id will be assigned by IANA.

3.1.1.3.  Reference

   Because an exporter terminates a long-lasting flow on a regular =
basis,
   the value of pktArrivalTimeOffset MUST be smaller than the active
   timeout period.

3.1.2.	pktLen

   Packet length in the IP packet.

3.1.2.1.  Type

   The pktLen element is of type int.

3.1.2.2.  Field Id

   The field id will be assigned by IANA.
  =20
  =20
  =20
  =20
  =20
  =20
Kim, et al.            expires - December, 2003             [Page 6]
=0C
Internet Draft            Per-packet Records               June 2003

3.1.3.	pktId

   The identification value of the IP packet.

3.1.3.1.  Type

   The pktId is of type short.

3.1.3.2.  Field Id

   The field id will be assigned by IANA.

3.1.4.	pktFlags

   The flags of the IP packet.

3.1.4.1.  Type

   The pktFlags is of type byte.

3.1.4.2.  Field Id

   The field id will be assigned by IANA.

3.1.5.	pktTtl

   The TTL value of the IP packet.

3.1.5.1.  Type

   The pktTtl is of type unsignedByte.

3.1.5.2.  Field Id

   The field id will be assigned by IANA.

3.1.6.	pktFragIndication

   The fragment field of the IP packet.

3.1.6.1.  Type

   The pktFragIndication is of type byte.

3.1.6.2.  Field Id

   The field id will be assigned by IANA.

3.1.7.	tcpFlags

   The flags in the TCP header of the IP packet.

Kim, et al.            expires - December, 2003             [Page 7]
=0C
Internet Draft            Per-packet Records               June 2003

3.1.7.1.  Type

   The tcpFlags is of type byte.

3.1.7.2.  Field Id

   The field id will be assigned by IANA.

3.1.8.	tcpSeqNumber

   The sequence number in the TCP header of the IP packet.

3.1.8.1.  Type

   The tcpSeqNumber is of type int.

3.1.8.2.  Field Id

   The field id will be assigned by IANA.

3.1.9.	tcpAckNumber

   The acknowledgement number in the TCP header of the IP packet.

3.1.9.1.  Type

   The tcpAckNumber is of type int.

3.1.9.2.  Field Id

   The field id will be assigned by IANA.

3.1.10.	pktEntirePayload

   The payload of the IP packet.

3.1.10.1.  Type

   The pktEntirePayload is of type string.=20

3.1.10.2.  Field Id

   The field id will be assigned by IANA.

3.1.10.3.  Reference

   When a predefined byte long part of an IP packet is captured,
   pktEntirePayload means the entire captured portion of the payload.
   The packet capture length can be configured during the initial=20
   communication between an exporter and a collector.
   For avoiding resource exhaustion and performance degradation, the
  =20
Kim, et al.            expires - December, 2003             [Page 8]
=0C
Internet Draft            Per-packet Records               June 2003

   use of pktEntirePayload element should be strictly conservative.
   The exporter, therefore, does not necessarily include
   a pktEntirePayload element to every packet information record;
   when a packet's payload contains a specific pattern, the exporter
   may append the pktEntirePayload element.

3.1.11.	pktPartialPayload

   The partial payload of the IP packet.

3.1.11.1.  Type

   The pktPartialPayload is of type string.

3.1.11.2.  Field Id

   The field id will be assigned by IANA.

3.1.11.3.  Reference

   During the initial communication between a collector and an =
exporter,
   operators can specify and assign some patterns (signatures) of =
interest.
   When an exporter detects a specific pattern in a packet's payload
   the exporter can append only the pattern in the pktPartialPayload =
field.
   The choice of appending an entire or a partial payload can also be
   configured. The exporter does not necessarily include a
   pktPartialPayload element to every packet information record;
   when a packet's payload contains a specific pattern, the exporter =
may
   append the pktPartialPayload element.

3.2.  Metering Process Extension

   The metering process defined in IPFIX architecture model [4]
   may be extended as specified in the followings.
  =20
3.2.1.	Metering Process Functions

   Flow classification specification may contain a flag enabling or
   disabling per-packet information export. If the flag is off, packets
   within the flow are processed as the existing manner in the =
architecture
   model [4]. If the flag is on, however, the Metering Process must =
generate
   per-packet information. When the flag is on and a specific pattern =
is
   assigned to the flow as well, the Metering Process needs to perform =
an=20
   additional pattern matching process on the basis of the pattern(s).
   When more than one patterns are specified for a flow, the Metering
   Process needs to execute the pattern matching task repetitively.
   When no pattern or a wildcard pattern is specified for a flow,
   the pattern matching process does not perform anything in effect.
   For a wildcard pattern specification, however, the pktEntirePayload
   or pktPartialPayload element must be generated and included in
   the per-packet records.=20
 =20
Kim, et al.            expires - December, 2003             [Page 9]
=0C
Internet Draft            Per-packet Records               June 2003


  =20
   The figure below describes the extended architecture of the Metering
   Process.

        packet capturing
               |
          timestamping
               |
               V
        +------+
        |      |
        |   sampling (1:1 in case of no sampling)
        |      |
        | classifying -------------+
        | (NULL when No criteria)  |
        |      |                   | =20
        +------+           pattern matching
               |   (NULL when No pattern or Wildcard pattern)
               |                   |
               V                   V=20
          Flow Records       Packet Records


3.2.2.	Selection Criteria for Packet Information Export

   The measurement device may define rules so that the information
   of packets within only a certain flow is exported. 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. The measurement device can
   include the rules in the Selection Criteria in the architecture
   model [4] and the flag enabling or disabling Per-Packet=20
   Information Export (PPIE) is called PPIE flag.
  =20
   Example: The per-packet information of flows whose=20
            {Protocol =3D=3D TCP, Destination Port =3D 80} are =
generated
            and exported.

3.2.3.	Pattern Specification and Pattern Matching

   A Pattern Specification is a pattern and its attributes. A Pattern
   Specification is composed as the following:
  =20
          Pattern Specification =3D <Pattern, Pattern Position>
         =20
   Pattern Position is composed of packet sequence range and byte=20
   range in which the pattern should be sought for.

   A Selection Criteria [4] whose PPIE flag is on may contain one
   or more Pattern Specifications; packets that suffice the Selection
   Criteria are investigated in searching for the patterns in=20
   the Pattern Specifications. This mechanism, in conjunction with
   the Pattern Position, restricts the excessive use of pattern
   matching function which may consume serious amount of computing
   and network resources.
              =20
Kim, et al.            expires - December, 2003             [Page 10]
=0C
Internet Draft            Per-packet Records               June 2003
  =20
   To implement the Pattern Matching process, the measurement process
   may use an efficient pattern matching algorithm. The specification=20
   of such an algorithm or a set of algorithms is out of the draft's=20
   scope. In IPFIX's context, the payload of a packet becomes the text
   on which pattern matching is performed. For fragmented packets,
   however, the pattern may occur in a separate form on a number of
   consecutive packets especially when the specified pattern is long.
   The pattern matching process, thus, should operate on a text =
obtained
   by reassembling packet fragments. On the other hand, the measurement
   device may not reassemble a transport layer segment when a long
   pattern takes place on the boundary of more than one packets.  =20
  =20
3.3.  Configuration Extension

   The Configuration specified in the requirement document [6]
   may be extended as specified in the followings.

3.3.1.	Configuration Extension for the Metering Process

   The Metering Process may provide a way of configuring the extended
   features in the Selection Criteria. The following parameters of the
   metering process MAY be configurable:

     1. specifications of flows whose constituting packets'=20
        information will be exported; this can be accomplished by
        adding the PPIE flag in the Selection Criteria.
     2. specifications of flows whose constituting packets'=20
        payload will be investigated in searching for patterns;
        this can be accomplished by adding the Pattern=20
        Specification in the Selection Criteria
     3. Pattern Specifications
     4. packet capture length; this should be uniformly applied
        to every packet in every flow of a measurement device

3.3.2.	Configuration Extension for the Exporting Process

   The Exporting Process may provide a way of configuring the following
   parameters:
  =20
     1. reporting data format for per-packet information
        Specifying the reporting data format for per-packet information
        must include a selection of attributes to be reported for each
        packet. Especially, in order to include a packet's payload in =
the
        reporting format, a corresponding Pattern Specification must be
        provided to the Metering Process because the exporter is =
confined
        to create a pktEntirePayload or a pktPartialPayload instance =
only
        when the packet's payload contains the pattern. When capturing
        every packet's payload is required, a wildcard pattern can be=20
        used. Using a wildcard pattern necessarily implies to include
        pktEntirePayload in the reporting format.
     2. Per-packet data export interval
        Detailed description on this parameter is given in section 3.4.
 =20
Kim, et al.            expires - December, 2003             [Page 11]
=0C
Internet Draft            Per-packet Records               June 2003

3.4.  Data Export Extension

   Since the data export protocol specified in [3] is extensible
   and configurable, there is no special extension required for =
adopting
   per-packet information export.
  =20
3.4.1.  Export Layout
  =20
   However, because a single instance of Data FlowSet can contain Flow
   Records of a single type, the measurement device can not combine the
   per-packet records into the same Data Flowset for the packets'
   corresponding flow. Instead, the exporter can define additional Data
   Flowset formats. On the basis of the selection of per-packet
   information elements specified in the section 3.1, the exporter can
   define a number of different Data Flowset formats. Defining new Data
   Flowsets is accomplished by introducing new Templates Records.
        =20
   A Data FlowSet for per-packet records contains the information of
   packets of a single flow. In order to convey the information of the
   corresponding flow to which the packets belong, another Data Flowset
   that conveys flow information must precede the Data FlowSet for
   per-packet records. The Data FlowSet conveying flow information must
   be disposed right ahead of the Data FlowSet conveying per-packet
   records. In order to convey enough information to couple the=20
   per-packet records with their corresponding flow, the Data FlowSet
   for flow information must contain at least the following six =
elements:
  =20
       1. Src IP Address
       2. Dst IP Address
       3. Src Port
       4. Dst Port
       5. Protocol Id
       6. Flow Creation Time
  =20
   The figure below shows the overall layout of an export packet
   containing per-packet records.
  =20
   =
+--------+-------------------------------------------------------------+=

   |        | +---------+     +--------------+ +--------------------+   =
  |
   | Packet | | Data    | ... | Data FlowSet | | Data FlowSet       | =
... |
   | Header | | FlowSet | ... | (Flow Info   | |(Per-packet Info of | =
... |
   |        | |         |     |  of flow X)  | | packets within X   |   =
  |
   |        | +---------+     +--------------+ +--------------------+   =
  |
   =
+--------+-------------------------------------------------------------+=

        =20
   The length of an export packet still should not exceed the local =
MTU.








Kim, et al.            expires - December, 2003             [Page 12]
=0C
Internet Draft            Per-packet Records               June 2003
 =20
3.4.2.  Export Interval
  =20
   The export interval of per-packet information should be supported in =

   either of the following ways:
  =20
      1. Per-packet records are exported when a corresponding flow is
         terminated.
      2. Per-packet records are exported on a regular period basis;
         The export period may be short enough to support near-realtime
         notification.
  =20
   When per-packet records are exported on a regular period basis,
   a Data FlowSet for per-packet records needs to be generated before
   the corresponding flow terminates. In this case, the exporting
   process needs to create a simple flow record before generating a=20
   full-fledged, expiration-based flow record.
  =20
3.5.  Collector Extension

   There is no extension required for the Collector.

4.  Security Considerations

   This document describes the requirements and elements of information
   model for supplementing IPFIX flow information with per-packet =
record.
   The security requirements for the IPFIX flow information are =
addressed
   in the IPFIX requirement draft and the same requirements must be=20
   considered for the extension proposed in this document as well.
   No further security threats are induced from this document.

5.  References

   [1] Colleen Shannon, David Moore, K Claffy, Characteristics of =
Fragmented
       IP Traffic on Internet Links, PAM 2001, 83 - 97. Nov. 2001.
   [2] Tanja Zseby, et. al.., IPFIX Applicability, =
draft-ietf-ipfix-as-00.txt,
       June 2003.
   [3] B. Claise, et. al.., IPFIX Protocol Specifications,
       draft-ietf-ipfix-protocol-00.txt, June 2003.
   [4] G. Sadasivan, et. al.., Architecture Model for IP Flow =
Information
       Export, draft-ietf-ipfix-arch-00.txt, June 2003.
   [5] P. Calato, et. al.., Information Model for IP Flow Information =
Export,
       draft-ietf-ipfix-info-00.txt, June 2003.
   [6] J. Quittek, et. al.., Requirements for IP Flow Information =
Export,
       draft-ietf-ipfix-reqs-10.txt, June 2003.
  =20
Author's Addresses

   Changhoon Kim
   Engineering Staff,
   ETRI, 161 Gajeong-Dong, Yuseong-Gu, Daejon, 305-350, South Korea
   kimch@etri.re.kr

   Taesang Choi
   Senior Engineering Staff,
   ETRI, 161 Gajeong-Dong, Yuseong-Gu, Daejon, 305-350, South Korea
   choits@etri.re.kr
  =20
Kim, et al.            expires - December, 2003             [Page 13]
------_=_NextPart_000_01C33B85.557424F0--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 26 05:11:02 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13202
	for <ipfix-archive@lists.ietf.org>; Thu, 26 Jun 2003 05:11:01 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19VRuX-00073b-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 26 Jun 2003 03:15:17 -0500
Received: from mail4.hitachi.co.jp ([133.145.228.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19VRuW-00073M-00
	for ipfix@net.doit.wisc.edu; Thu, 26 Jun 2003 03:15:16 -0500
Received: from mc2.mcg.hitachi.co.jp by mail4.hitachi.co.jp (8.9.3p2/3.7W-mail4) id RAA15868; Thu, 26 Jun 2003 17:15:13 +0900 (JST)
Received: (from root@localhost)
	by mc2.mcg.hitachi.co.jp (8.11.6+Sun/8.11.6) id h5Q8FCM05110
	for <ipfix@net.doit.wisc.edu>; Thu, 26 Jun 2003 17:15:12 +0900 (JST)
Received: from unknown [192.168.2.1] by mc2.mcg.hitachi.co.jp with SMTP id TAA05109 ; Thu, 26 Jun 2003 17:15:12 +0900
Received: from navsg2.hitachi.co.jp by navsg2.hitachi.co.jp (8.9.3/3.7W-navsg2) id RAA05652; Thu, 26 Jun 2003 17:15:12 +0900 (JST)
Received: from hsdlgw92.sdl.hitachi.co.jp ([133.144.7.20])
 by navsg2.hitachi.co.jp (NAVGW 2.5.2.17) with SMTP id M2003062617151118439
 for <ipfix@net.doit.wisc.edu>; Thu, 26 Jun 2003 17:15:11 +0900
Received: from vgate.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.9.3/3.7W01100113) id RAA14747; Thu, 26 Jun 2003 17:15:11 +0900
Received: from yokolab1.sdl.hitachi.co.jp ([133.144.101.11])
 by vgate.sdl.hitachi.co.jp (SAVSMTP 3.0.1.45) with SMTP id M2003062617150929172
 for <ipfix@net.doit.wisc.edu>; Thu, 26 Jun 2003 17:15:09 +0900
Received: from hitachiialx8tm (dhcp4-70.sdl.hitachi.co.jp [133.144.4.70])
	by yokolab1.sdl.hitachi.co.jp (8.9.3/3.7W02021014) with ESMTP id RAA15524
	for <ipfix@net.doit.wisc.edu>; Thu, 26 Jun 2003 17:15:11 +0900
From: "David Diep" <diep@sdl.hitachi.co.jp>
To: <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] Per-packet record proposal
Date: Thu, 26 Jun 2003 17:15:54 +0900
Message-ID: <001301c33bbb$2a0bded0$46049085@hitachiialx8tm>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0014_01C33C06.99F386D0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <A870CB5EE2A3D5118D0C00D0B7A8D8F5022B96B1@cms2>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.

------=_NextPart_000_0014_01C33C06.99F386D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,
 
The per-packet information could be used in QoS passive measurement when
the meter needs to export a list of packet identifier (packetID) and the
associated timestamps. In order to reduce the packetID collision a
classical scheme is to generate the packetID based on packet header and
packet payload and then to use CRC-32 function. In the presented
document the pktId type is defined as short type. I think that in order
to be used with a low collision probability as the packetID, the type of
the pktId parameter should be based at least on a 32-bits type.
 
Best Regards,
 
David Diep 
 
-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On
Behalf Of choits@etri.re.kr
Sent: Thursday, June 26, 2003 10:51 AM
To: ipfix@net.doit.wisc.edu
Cc: psam@ops.ietf.org; n.brownlee@auckland.ac.nz; kimch@etri.re.kr;
tsjeong@etri.re.kr
Subject: [ipfix] Per-packet record proposal
 
Dear IPFIXers, 
We have read through a set of IPFIX drafts and found that it may be
useful to extend the IPFIX information model, metering process,
configuration, and data export as described in the attached draft.  We
provided the rationale of our proposal and necessary extensions in the
document in detail.  We would highly apprciate your time for reading and
commenting it.
We submitted this document as an individual submission but it hasn't
been registered in the IETF internet draft registery yet.  Thus, I
attached the document for your easiler reference.  
Sincerely, 
Taesang, Changhoon 
ETRI 
  

------=_NextPart_000_0014_01C33C06.99F386D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C33C06.99ABA860">
<title>Per-packet record proposal</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:\5B8B\4F53;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;
	mso-font-alt:\AD74\B9BC;
	mso-font-charset:129;
	mso-generic-font-family:roman;
	mso-font-pitch:auto;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:"\@Gulim";
	panose-1:2 11 6 0 0 1 1 1 1 1;
	mso-font-charset:129;
	mso-generic-font-family:roman;
	mso-font-pitch:auto;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:Gulim;
	mso-bidi-font-family:Gulim;
	mso-fareast-language:KO;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:Gulim;
	mso-bidi-font-family:Gulim;
	mso-fareast-language:KO;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The per-packet information could be =
used
in QoS passive measurement when the meter needs to export a list of =
packet
identifier (<span class=3DSpellE>packetID</span>) and the associated =
timestamps.
In order to reduce the <span class=3DSpellE>packetID</span> collision a =
classical
scheme is to generate the <span class=3DSpellE>packetID</span> based on =
packet
header and packet payload and then to use CRC-32 function. In the =
presented
document the <span class=3DSpellE>pktId</span> type is defined as short =
type. I
think that in order to be used with a low collision probability as the =
<span
class=3DSpellE>packetID</span>, the type of the <span =
class=3DSpellE>pktId</span>
parameter should be based at least on a 32-bits =
type.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Best =
Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>David Diep =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> majordomo =
listserver
[mailto:majordomo@mil.doit.wisc.edu] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>choits@etri.re.kr<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 26, =
2003
10:51 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
ipfix@net.doit.wisc.edu<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> psam@ops.ietf.org;
n.brownlee@auckland.ac.nz; kimch@etri.re.kr; tsjeong@etri.re.kr<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [ipfix] =
Per-packet record
proposal</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3DGulim><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3DGulim><span =
style=3D'font-size:
10.0pt'>Dear IPFIXers,</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3DGulim><span =
style=3D'font-size:
10.0pt'>We have read through a set of IPFIX drafts and found that it may =
be
useful to extend the IPFIX information model, metering process, =
configuration,
and data export as described in the attached draft.&nbsp; We provided =
the
rationale of our proposal and necessary extensions in the document in
detail.&nbsp; We would highly apprciate your time for reading and =
commenting
it.</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3DGulim><span =
style=3D'font-size:
10.0pt'>We submitted this document as an individual submission but it =
hasn't
been registered in the IETF internet draft registery yet.&nbsp; Thus, I
attached the document for your easiler reference.&nbsp; =
</span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3DGulim><span =
style=3D'font-size:
10.0pt'>Sincerely,</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3DGulim><span =
style=3D'font-size:
10.0pt'>Taesang, Changhoon</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>ETRI</span></font> =
<o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D3 face=3DGulim><span =
style=3D'font-size:
12.0pt'>&nbsp; <o:p></o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0014_01C33C06.99F386D0--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 26 05:18:46 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13378
	for <ipfix-archive@lists.ietf.org>; Thu, 26 Jun 2003 05:18:46 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19VSge-00012g-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 26 Jun 2003 04:05:00 -0500
Received: from cms1.etri.re.kr ([129.254.16.11])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19VSgc-00012Q-00
	for ipfix@net.doit.wisc.edu; Thu, 26 Jun 2003 04:04:58 -0500
Received: from etri.re.kr (TASSAJARA [129.254.70.152]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id NAHCSBGK; Thu, 26 Jun 2003 18:04:47 +0900
Message-ID: <3EFAB736.731B0202@etri.re.kr>
Date: Thu, 26 Jun 2003 18:04:54 +0900
From: Changhoon Kim <kimch@etri.re.kr>
Organization: ETRI
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: David Diep <diep@sdl.hitachi.co.jp>
CC: ipfix@net.doit.wisc.edu, choits@etri.re.kr
Subject: Re: [ipfix] Per-packet record proposal (pktId)
References: <001301c33bbb$2a0bded0$46049085@hitachiialx8tm>
Content-Type: multipart/alternative;
 boundary="------------CF013B5E7AD7E1B3A91BCD43"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


--------------CF013B5E7AD7E1B3A91BCD43
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi David,

Thank you for your interest and comment.

We intended to use the pktId element to contain the 16-bit
identification value in the IP header.
The identification is a host-local value and incremented by one each
time a datagram is sent by the src host.
The field plays an important role for reassemblying packet fragments and
for detecting some routing anomalies;
when two packets within a flow have the same id (with different
timestamps), it guarantees that there exists a routing loop on the
flow's path. We, thus, see that the pktId element should contain the
value of the identification field without additional processing.

If the consensus of the group is turned out to define another element
for identifying every packet in a globally unique way, then we may be
able to add another element for that purpose.

Best,

- Chang


David Diep wrote:

> Hi,
>
> The per-packet information could be used in QoS passive measurement
> when the meter needs to export a list of packet identifier (packetID)
> and the associated timestamps. In order to reduce the packetID
> collision a classical scheme is to generate the packetID based on
> packet header and packet payload and then to use CRC-32 function. In
> the presented document the pktId type is defined as short type. I
> think that in order to be used with a low collision probability as
> the packetID, the type of the pktId parameter should be based at least
> on a 32-bits type.
>
> Best Regards,
>
> David Diep
>
> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On
> Behalf Of choits@etri.re.kr
> Sent: Thursday, June 26, 2003 10:51 AM
> To: ipfix@net.doit.wisc.edu
> Cc: psam@ops.ietf.org; n.brownlee@auckland.ac.nz; kimch@etri.re.kr;
> tsjeong@etri.re.kr
> Subject: [ipfix] Per-packet record proposal
>
> Dear IPFIXers,
>
> We have read through a set of IPFIX drafts and found that it may be
> useful to extend the IPFIX information model, metering process,
> configuration, and data export as described in the attached draft.  We
> provided the rationale of our proposal and necessary extensions in the
> document in detail.  We would highly apprciate your time for reading
> and commenting it.
>
> We submitted this document as an individual submission but it hasn't
> been registered in the IETF internet draft registery yet.  Thus, I
> attached the document for your easiler reference.
>
> Sincerely,
>
> Taesang, Changhoon
> ETRI
>
--
==================================================
Chang H. Kim

Engineer
Internet Traffic Management Team
Electronics and Telecom Research Institute (ETRI)
kimch@etri.re.kr
http://chang.miner.ne.kr

Office : +82-42-860-5801
Mobile : +82-19-226-6305
Fax : +82-42-860-5440
==================================================
Let's roll!


--------------CF013B5E7AD7E1B3A91BCD43
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body link="#0000FF" vlink="#800080" lang="EN-US" style="tab-interval:.5in">
Hi David,
<p>Thank you for your interest and comment.
<p>We intended to use the pktId element to contain the 16-bit identification
value in the IP header.
<br>The identification is a host-local value and incremented by one each
time a datagram is sent by the src host.
<br>The field plays an important role for reassemblying packet fragments
and for detecting some routing anomalies;
<br>when two packets within a flow have the same id (with different timestamps),
it guarantees that there exists a routing loop on the flow's path. We,
thus, see that the pktId element should contain the value of the identification
field without additional processing.
<p>If the consensus of the group is turned out to define another element
for identifying every packet in a globally unique way, then we may be able
to add another element for that purpose.
<p>Best,
<p>- Chang
<br>&nbsp;
<p>David Diep wrote:
<blockquote TYPE=CITE><link rel=File-List href="cid:filelist.xml@01C33C06.99ABA860"><!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:\5B8B\4F53;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;
	mso-font-alt:\AD74\B9BC;
	mso-font-charset:129;
	mso-generic-font-family:roman;
	mso-font-pitch:auto;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:"\@Gulim";
	panose-1:2 11 6 0 0 1 1 1 1 1;
	mso-font-charset:129;
	mso-generic-font-family:roman;
	mso-font-pitch:auto;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:Gulim;
	mso-bidi-font-family:Gulim;
	mso-fareast-language:KO;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:Gulim;
	mso-bidi-font-family:Gulim;
	mso-fareast-language:KO;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */ 
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
<div class=Section1>
<div class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><font face="Arial"><font color="#000080"><font size=-1>Hi,</font></font></font><o:p></o:p></span></div>


<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><font face="Arial"><font color="#000080"><font size=-1>The
per-packet information could be used in QoS passive measurement when the
meter needs to export a list of packet identifier (<span class=SpellE>packetID</span>)
and the associated timestamps. In order to reduce the&nbsp;<span class=SpellE>packetID</span>
collision a classical scheme is to generate the&nbsp;<span class=SpellE>packetID</span>
based on packet header and packet payload and then to use CRC-32 function.
In the presented document the&nbsp;<span class=SpellE>pktId</span> type
is defined as short type. I think that in order to be used with a low collision
probability as the&nbsp;<span 
class=SpellE>packetID</span>, the type of
the&nbsp;<span class=SpellE>pktId</span> parameter should be based at least
on a 32-bits type.</font></font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><font face="Arial"><font color="#000080"><font size=-1>Best
Regards,</font></font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><font face="Arial"><font color="#000080"><font size=-1>David
Diep&nbsp;</font></font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p></o:p></span>

<p class="MsoNormal" style="margin-left:.5in"><span 
style='font-size:10.0pt;font-family:Tahoma'><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><span style='font-weight:bold'><font face="Tahoma"><font size=-1><b>From:</span></b>
majordomo listserver [<A HREF="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</A>]&nbsp;<span style='font-weight:bold'><b>On
Behalf Of&nbsp;</span></b>choits@etri.re.kr</font></font>
<br><span style='font-weight:bold'><font face="Tahoma"><font size=-1><b>Sent:</span></b>
Thursday, June 26, 2003 10:51 AM</font></font>
<br><span style='font-weight:bold'><font face="Tahoma"><font size=-1><b>To:</span></b>
ipfix@net.doit.wisc.edu</font></font>
<br><span style='font-weight:bold'><font face="Tahoma"><font size=-1><b>Cc:</span></b>
psam@ops.ietf.org; n.brownlee@auckland.ac.nz; kimch@etri.re.kr; tsjeong@etri.re.kr</font></font>
<br><span style='font-weight:bold'><font face="Tahoma"><font size=-1><b>Subject:</span></b>
[ipfix] Per-packet record proposal</font></font></span>

<p class="MsoNormal" style="margin-left:.5in"><span 
style='font-size:12.0pt'><o:p></o:p></span>

<p style="margin-left:.5in"><span style='font-size:
10.0pt'><font face="Gulim"><font size=-1>Dear
IPFIXers,</font></font></span><o:p></o:p>

<p style="margin-left:.5in"><span style='font-size:
10.0pt'><font face="Gulim"><font size=-1>We
have read through a set of IPFIX drafts and found that it may be useful
to extend the IPFIX information model, metering process, configuration,
and data export as described in the attached draft.&nbsp; We provided the
rationale of our proposal and necessary extensions in the document in detail.&nbsp;
We would highly apprciate your time for reading and commenting it.</font></font></span><o:p></o:p>

<p style="margin-left:.5in"><span style='font-size:
10.0pt'><font face="Gulim"><font size=-1>We
submitted this document as an individual submission but it hasn't been
registered in the IETF internet draft registery yet.&nbsp; Thus, I attached
the document for your easiler reference.&nbsp;</font></font></span><o:p></o:p>

<p style="margin-left:.5in"><span style='font-size:
10.0pt'><font face="Gulim"><font size=-1>Sincerely,</font></font></span><o:p></o:p>

<p style="margin-left:.5in"><span style='font-size:
10.0pt'><font face="Gulim"><font size=-1>Taesang,
Changhoon</font></font></span>
<br><span style='font-size:10.0pt'><font size=-1>ETRI</font></span><o:p></o:p>

<p style="margin-left:.5in"><span style='font-size:
12.0pt'><o:p></o:p></span></div>
</blockquote>

<p>--
<br>==================================================
<br>Chang H. Kim
<p>Engineer
<br>Internet Traffic Management Team
<br>Electronics and Telecom Research Institute (ETRI)
<br>kimch@etri.re.kr
<br><A HREF="http://chang.miner.ne.kr">http://chang.miner.ne.kr</A>
<p>Office : +82-42-860-5801
<br>Mobile : +82-19-226-6305
<br>Fax : +82-42-860-5440
<br>==================================================
<br>Let's roll!
<br>&nbsp;
</body>
</html>

--------------CF013B5E7AD7E1B3A91BCD43--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 26 06:37:39 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14649
	for <ipfix-archive@lists.ietf.org>; Thu, 26 Jun 2003 06:37:38 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19VTyI-0004C6-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 26 Jun 2003 05:27:18 -0500
Received: from mail4.hitachi.co.jp ([133.145.228.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19VTyG-0004Bv-00
	for ipfix@net.doit.wisc.edu; Thu, 26 Jun 2003 05:27:17 -0500
Received: from mc2.mcg.hitachi.co.jp by mail4.hitachi.co.jp (8.9.3p2/3.7W-mail4) id TAA22981; Thu, 26 Jun 2003 19:27:15 +0900 (JST)
Received: (from root@localhost)
	by mc2.mcg.hitachi.co.jp (8.11.6+Sun/8.11.6) id h5QARDX17033
	for <ipfix@net.doit.wisc.edu>; Thu, 26 Jun 2003 19:27:13 +0900 (JST)
Received: from unknown [192.168.2.1] by mc2.mcg.hitachi.co.jp with SMTP id VAA17032 ; Thu, 26 Jun 2003 19:27:13 +0900
Received: from navsg4.hitachi.co.jp by navsg4.hitachi.co.jp (8.9.3/3.7W-navsg4) id TAA07288; Thu, 26 Jun 2003 19:27:13 +0900 (JST)
Received: from hsdlgw92.sdl.hitachi.co.jp ([133.144.7.20])
 by navsg4.hitachi.co.jp (NAVGW 2.5.2.17) with SMTP id M2003062619271326170
 ; Thu, 26 Jun 2003 19:27:13 +0900
Received: from vgate.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.9.3/3.7W01100113) id TAA23647; Thu, 26 Jun 2003 19:27:12 +0900
Received: from yokolab1.sdl.hitachi.co.jp ([133.144.101.11])
 by vgate.sdl.hitachi.co.jp (SAVSMTP 3.0.1.45) with SMTP id M2003062619271114483
 ; Thu, 26 Jun 2003 19:27:11 +0900
Received: from hitachiialx8tm (dhcp4-70.sdl.hitachi.co.jp [133.144.4.70])
	by yokolab1.sdl.hitachi.co.jp (8.9.3/3.7W02021014) with ESMTP id TAA19270;
	Thu, 26 Jun 2003 19:27:12 +0900
From: "David Diep" <diep@sdl.hitachi.co.jp>
To: "'Changhoon Kim'" <kimch@etri.re.kr>
Cc: <ipfix@net.doit.wisc.edu>, <choits@etri.re.kr>
Subject: RE: [ipfix] Per-packet record proposal (pktId)
Date: Thu, 26 Jun 2003 19:27:56 +0900
Message-ID: <003001c33bcd$9b9ae520$46049085@hitachiialx8tm>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0031_01C33C19.0B828D20"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <3EFAB736.731B0202@etri.re.kr>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01C33C19.0B828D20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Chang,
 
If you use IP header "identification" field for any flow this is
problematic because this value is unique for a "source-destination pair
and protocol for the time the datagram will be active in the internet
system". To my understanding the flow definition of IPFIX is much more
flexible ("This definition covers the range from a flow containing all
packets observed at a network interface to a flow consisting of just a
single packet" from draft-ietf-ipfix-protocol-00.txt). Consequently your
probability of collision may be high depending on the flow type that you
consider so in the general case, you will not be able to conclude
anything about rooting loop in case you have two times the same id for a
given flow.
 
Last point, you're a using an IPv4 specific feature that you can't
extend directly to IPv6 traffic.
 
Regards,
 
David
 
-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On
Behalf Of Changhoon Kim
Sent: Thursday, June 26, 2003 6:05 PM
To: David Diep
Cc: ipfix@net.doit.wisc.edu; choits@etri.re.kr
Subject: Re: [ipfix] Per-packet record proposal (pktId)
 
Hi David, 
Thank you for your interest and comment. 
We intended to use the pktId element to contain the 16-bit
identification value in the IP header. 
The identification is a host-local value and incremented by one each
time a datagram is sent by the src host. 
The field plays an important role for reassemblying packet fragments and
for detecting some routing anomalies; 
when two packets within a flow have the same id (with different
timestamps), it guarantees that there exists a routing loop on the
flow's path. We, thus, see that the pktId element should contain the
value of the identification field without additional processing. 
If the consensus of the group is turned out to define another element
for identifying every packet in a globally unique way, then we may be
able to add another element for that purpose. 
Best, 
- Chang 
  
David Diep wrote: 
Hi,
The per-packet information could be used in QoS passive measurement when
the meter needs to export a list of packet identifier (packetID) and the
associated timestamps. In order to reduce the packetID collision a
classical scheme is to generate the packetID based on packet header and
packet payload and then to use CRC-32 function. In the presented
document the pktId type is defined as short type. I think that in order
to be used with a low collision probability as the packetID, the type of
the pktId parameter should be based at least on a 32-bits type. 
Best Regards, 
David Diep  
-----Original Message----- 
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On
Behalf Of choits@etri.re.kr 
Sent: Thursday, June 26, 2003 10:51 AM 
To: ipfix@net.doit.wisc.edu 
Cc: psam@ops.ietf.org; n.brownlee@auckland.ac.nz; kimch@etri.re.kr;
tsjeong@etri.re.kr 
Subject: [ipfix] Per-packet record proposal 
Dear IPFIXers, 
We have read through a set of IPFIX drafts and found that it may be
useful to extend the IPFIX information model, metering process,
configuration, and data export as described in the attached draft.  We
provided the rationale of our proposal and necessary extensions in the
document in detail.  We would highly apprciate your time for reading and
commenting it. 
We submitted this document as an individual submission but it hasn't
been registered in the IETF internet draft registery yet.  Thus, I
attached the document for your easiler reference.  
Sincerely, 
Taesang, Changhoon 
ETRI 
-- 
================================================== 
Chang H. Kim 
Engineer 
Internet Traffic Management Team 
Electronics and Telecom Research Institute (ETRI) 
kimch@etri.re.kr 
http://chang.miner.ne.kr 
Office : +82-42-860-5801 
Mobile : +82-19-226-6305 
Fax : +82-42-860-5440 
================================================== 
Let's roll! 
  

------=_NextPart_000_0031_01C33C19.0B828D20
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C33C19.0B1F3770">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:\5B8B\4F53;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;
	mso-font-alt:\AD74\B9BC;
	mso-font-charset:129;
	mso-generic-font-family:roman;
	mso-font-pitch:auto;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:"\@Gulim";
	panose-1:2 11 6 0 0 1 1 1 1 1;
	mso-font-charset:129;
	mso-generic-font-family:roman;
	mso-font-pitch:auto;
	mso-font-signature:-1342176593 1775729915 48 0 524447 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:Gulim;
	mso-bidi-font-family:Gulim;
	mso-fareast-language:KO;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:Gulim;
	mso-bidi-font-family:Gulim;
	mso-fareast-language:KO;}
span.EmailStyle18
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi =
Chang,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>If you use IP header =
&#8220;identification&#8221;
field for any flow this is problematic because this value is unique for =
a &#8220;source-destination
pair and protocol for the time the datagram will be active in the =
internet system&#8221;.
To my understanding the flow definition of IPFIX is much more flexible =
(&#8220;This
definition covers the range from a flow containing all packets observed =
at a
network interface to a flow consisting of just a single packet&#8221; =
from draft-ietf-ipfix-protocol-00.txt).
Consequently your probability of collision may be high depending on the =
flow type
that you consider so in the general case, you will not be able to =
conclude anything
about rooting loop in case you have two times the same id for a given =
flow.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Last point, you&#8217;re a using an =
IPv4
specific feature that you can&#8217;t extend directly to IPv6 =
traffic&#8230;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>David<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;mso-fareast-font-family:SimS=
un;
mso-fareast-language:ZH-CN'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> majordomo =
listserver
[mailto:majordomo@mil.doit.wisc.edu] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Changhoon Kim<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 26, =
2003 6:05
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> David Diep<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
ipfix@net.doit.wisc.edu;
choits@etri.re.kr<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [ipfix] =
Per-packet
record proposal (pktId)</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3DGulim><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3DGulim><span
style=3D'font-size:12.0pt'>Hi David, <o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D3 face=3DGulim><span =
style=3D'font-size:
12.0pt'>Thank you for your interest and comment. =
<o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D3 face=3DGulim><span =
style=3D'font-size:
12.0pt'>We intended to use the pktId element to contain the 16-bit
identification value in the IP header. <br>
The identification is a host-local value and incremented by one each =
time a
datagram is sent by the src host. <br>
The field plays an important role for reassemblying packet fragments and =
for
detecting some routing anomalies; <br>
when two packets within a flow have the same id (with different =
timestamps), it
guarantees that there exists a routing loop on the flow's path. We, =
thus, see
that the pktId element should contain the value of the identification =
field
without additional processing. <o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D3 face=3DGulim><span =
style=3D'font-size:
12.0pt'>If the consensus of the group is turned out to define another =
element
for identifying every packet in a globally unique way, then we may be =
able to
add another element for that purpose. <o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D3 face=3DGulim><span =
style=3D'font-size:
12.0pt'>Best, <o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D3 face=3DGulim><span =
style=3D'font-size:
12.0pt'>- Chang <br>
&nbsp; <o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D3 face=3DGulim><span =
style=3D'font-size:
12.0pt'>David Diep wrote: <o:p></o:p></span></font></p>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' =
TYPE=3DCITE><!--[if gte mso 9]><xml>
 <u1:OfficeDocumentSettings>
  <u1:DoNotRelyOnCSS/>
 </u1:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <u2:WordDocument>
  <u2:SpellingState>Clean</u2:SpellingState>
  <u2:GrammarState>Clean</u2:GrammarState>
  <u2:DocumentKind>DocumentEmail</u2:DocumentKind>
  <u2:EnvelopeVis/>
  <u2:Compatibility>
   <u2:UseFELayout/>
  </u2:Compatibility>
  <u2:BrowserLevel>MicrosoftInternetExplorer4</u2:BrowserLevel>
 </u2:WordDocument>
</xml><![endif]-->

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Hi,<u3:p></u3:p><=
/span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><u3:p></u3:p>The
per-packet information could be used in QoS passive measurement when the =
meter
needs to export a list of packet identifier (packetID) and the =
associated
timestamps. In order to reduce the&nbsp;packetID collision a classical =
scheme
is to generate the&nbsp;packetID based on packet header and packet =
payload and
then to use CRC-32 function. In the presented document the&nbsp;pktId =
type is defined
as short type. I think that in order to be used with a low collision
probability as the&nbsp;packetID, the type of the&nbsp;pktId parameter =
should
be based at least on a 32-bits type.<u3:p></u3:p></span></font> =
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><u3:p></u3:p>Best=
 Regards,<u3:p></u3:p></span></font>
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><u3:p></u3:p>Davi=
d Diep&nbsp;<u3:p></u3:p></span></font>
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'><u3:p></u3:p>-----Original
Message----- <br>
<b><span style=3D'font-weight:bold'>From:</span></b> majordomo =
listserver [<a
href=3D"mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wis=
c.edu</a>]&nbsp;<b><span
style=3D'font-weight:bold'>On Behalf =
Of&nbsp;</span></b>choits@etri.re.kr <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 26, =
2003
10:51 AM <br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
ipfix@net.doit.wisc.edu <br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> psam@ops.ietf.org;
n.brownlee@auckland.ac.nz; kimch@etri.re.kr; tsjeong@etri.re.kr <br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [ipfix] =
Per-packet record
proposal</span></font> <o:p></o:p></p>

<p style=3D'margin-left:1.0in'><font size=3D2 face=3DGulim><span =
style=3D'font-size:
10.0pt'><u3:p></u3:p>Dear IPFIXers,</span></font><u3:p></u3:p> =
<o:p></o:p></p>

<p style=3D'margin-left:1.0in'><font size=3D2 face=3DGulim><span =
style=3D'font-size:
10.0pt'>We have read through a set of IPFIX drafts and found that it may =
be
useful to extend the IPFIX information model, metering process, =
configuration,
and data export as described in the attached draft.&nbsp; We provided =
the
rationale of our proposal and necessary extensions in the document in
detail.&nbsp; We would highly apprciate your time for reading and =
commenting it.</span></font><u3:p></u3:p>
<o:p></o:p></p>

<p style=3D'margin-left:1.0in'><font size=3D2 face=3DGulim><span =
style=3D'font-size:
10.0pt'>We submitted this document as an individual submission but it =
hasn't
been registered in the IETF internet draft registery yet.&nbsp; Thus, I
attached the document for your easiler =
reference.&nbsp;</span></font><u3:p></u3:p>
<o:p></o:p></p>

<p style=3D'margin-left:1.0in'><font size=3D2 face=3DGulim><span =
style=3D'font-size:
10.0pt'>Sincerely,</span></font><u3:p></u3:p> <o:p></o:p></p>

<p style=3D'margin-left:1.0in'><font size=3D2 face=3DGulim><span =
style=3D'font-size:
10.0pt'>Taesang, Changhoon</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>ETRI</span></font><u3:p></u3:p> =
<o:p></o:p></p>

</blockquote>

<p style=3D'margin-left:.5in'><font size=3D3 face=3DGulim><span =
style=3D'font-size:
12.0pt'><u3:p></u3:p>-- <br>
=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 <br>
Chang H. Kim <o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D3 face=3DGulim><span =
style=3D'font-size:
12.0pt'>Engineer <br>
Internet Traffic Management Team <br>
Electronics and Telecom Research Institute (ETRI) <br>
kimch@etri.re.kr <br>
<a href=3D"http://chang.miner.ne.kr">http://chang.miner.ne.kr</a> =
<o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D3 face=3DGulim><span =
style=3D'font-size:
12.0pt'>Office : +82-42-860-5801 <br>
Mobile : +82-19-226-6305 <br>
Fax : +82-42-860-5440 <br>
=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 <br>
Let's roll! <br>
&nbsp; <o:p></o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0031_01C33C19.0B828D20--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 26 15:54:08 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18553
	for <ipfix-archive@lists.ietf.org>; Thu, 26 Jun 2003 15:54:08 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19VcYY-0003IZ-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 26 Jun 2003 14:37:18 -0500
Received: from relay.pair.com ([209.68.1.20])
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 19VcYX-0003IT-00
	for ipfix@net.doit.wisc.edu; Thu, 26 Jun 2003 14:37:17 -0500
Received: (qmail 17319 invoked from network); 26 Jun 2003 19:37:16 -0000
Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137)
  by relay.pair.com with SMTP; 26 Jun 2003 19:37:16 -0000
X-pair-Authenticated: 207.237.37.137
Received: from sphynx (sphynx [192.168.0.64])
	by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h5QJbG904438;
	Thu, 26 Jun 2003 15:37:16 -0400
From: "Carter Bullard" <carter@qosient.com>
To: "'Simon Leinen'" <simon@limmat.switch.ch>,
        "'Nevil Brownlee'" <n.brownlee@auckland.ac.nz>
Cc: "'Ganesh Sadasivan'" <gsadasiv@cisco.com>,
        "'Harrington,David'" <dbh@enterasys.com>, <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] Re: [ipfix-reqs] Flow definition
Date: Thu, 26 Jun 2003 15:37:07 -0400
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607EAF6@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.4510
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661689AB@ptah.newyork.qosient.com>
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Gentle people,
   I agree with Simon and want to add that encapsulations
are not the only extension issue, as there are metrics
that we vendors will want to transport that are not in
any of the drafts.  Just as long as we have a decent
vendor extension strategy then there will not be any
problem.

Carter



> -----Original Message-----
> From: majordomo listserver 
> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Simon Leinen
> Sent: Thursday, June 26, 2003 3:31 PM
> To: Nevil Brownlee
> Cc: Simon Leinen; Ganesh Sadasivan; Harrington,David; 
> ipfix@net.doit.wisc.edu
> Subject: [ipfix] Re: [ipfix-reqs] Flow definition
> 
> 
> Nevil Brownlee writes:
> > Hi Simon:
> 
> >> Ganesh Sadasivan writes:
> >> > Thanks David. I re-read the charter & agree that the charter does
> >> > not mention about MPLS flows. But the question is if 
> flow collection
> >> > is done on MPLS encapsulated IP packet ? If so should we not
> >> > explicitly include them in the flow definition.
> >> 
> >> I would say no, we shouldn't.
> 
> > I've been working with Ganesh on editing the Architecture Draft.
> > Seems to me that this is an issue which needs more discussion.
> > Here's my thoughts on it:
> 
> >  - If a network element (switch or router) understands things like
> >    MPLS, it makes sense to let it use that understanding in creating
> >    flows.
> 
> Maybe, but MPLS is just one of many possible encapsulations for IP
> packets.  I don't think MPLS-specific attributes should be treated any
> differently from e.g. attributes that are specific to ATM, Ethernet,
> Frame Relay, POS.  This would be a somewhat open-ended endeavour, so
> I'd like to keep this out of the base IPFIX standards.
> 
> Just defined MPLS-specific IPFIX attributes in a specific-lower-layer
> extension to IPFIX.  There can be other extensions for Ethernet etc.
> 
> >  - On the other hand, we have to define a 'base specification,'
> >    i.e. what's the minimum set of packet attributes an IPFIX
> >    exporter MUST support if it claims to be IPFIX-conformant?
> 
> >  - It's very difficult to decide where to draw the line on this.
> >    MPLS is clear enough, but how about other encapsulations,
> >    e.g. IP-in-IP, GRE, etc.?  Application information, e.g. in
> >    RTP header fields [RFC1889], raises even more questions.
> 
> > How about the following as a minimal definition for the header
> > fields which can define a flow?  (This is one of three list items in
> > the current Architecture Draft).
> 
> > * One or more header fields of the actual packet, e.g. destination
> >    IP address, or one of the fields in the packet's encapsulation
> >    header, e.g. label for MPLS, tunnel end-points for IP-in-IP, etc.
> 
> > The IPFIX Information Model could specify encapsulation-header-based
> > attributes as they seem neccessary and/or useful ...
> 
> Yes, but I suggest to keep specific lower layers out of the base
> document set.
> -- 
> Simon.
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
> 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 Jun 26 16:41:06 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20640
	for <ipfix-archive@lists.ietf.org>; Thu, 26 Jun 2003 16:41:06 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19VcSx-0003Bm-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 26 Jun 2003 14:31:31 -0500
Received: from babar.switch.ch ([130.59.4.85])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19VcSw-0003Bh-00
	for ipfix@net.doit.wisc.edu; Thu, 26 Jun 2003 14:31:30 -0500
Received: from babar.switch.ch (localhost [IPv6:::1])
	by babar.switch.ch (8.12.9+Sun/8.12.2) with ESMTP id h5QJV8EI025923;
	Thu, 26 Jun 2003 21:31:08 +0200 (CEST)
Received: (from leinen@localhost)
	by babar.switch.ch (8.12.9+Sun/8.12.2/Submit) id h5QJV6od025922;
	Thu, 26 Jun 2003 21:31:06 +0200 (CEST)
X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f
To: Nevil Brownlee <n.brownlee@auckland.ac.nz>
Cc: Simon Leinen <simon@limmat.switch.ch>,
        Ganesh Sadasivan <gsadasiv@cisco.com>,
        "Harrington,David" <dbh@enterasys.com>, ipfix@net.doit.wisc.edu
Subject: [ipfix] Re: [ipfix-reqs] Flow definition
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
   7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
From: Simon Leinen <simon@limmat.switch.ch>
In-Reply-To: <1056496459.e98a9a3bd377b@hotlava.auckland.ac.nz> (Nevil
 Brownlee's message of "Wed, 25 Jun 2003 11:14:19 +1200")
References: <6D745637A7E0F94DA070743C55CDA9BA603331@NHROCMBX1.ets.enterasys.com>
	<3EF7337F.9321FD8C@cisco.com> <aawufbvra5.fsf@limmat.switch.ch>
	<1056496459.e98a9a3bd377b@hotlava.auckland.ac.nz>
Date: Thu, 26 Jun 2003 21:31:06 +0200
Message-ID: <aa3chw7i11.fsf@limmat.switch.ch>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2.95 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Nevil Brownlee writes:
> Hi Simon:

>> Ganesh Sadasivan writes:
>> > Thanks David. I re-read the charter & agree that the charter does
>> > not mention about MPLS flows. But the question is if flow collection
>> > is done on MPLS encapsulated IP packet ? If so should we not
>> > explicitly include them in the flow definition.
>> 
>> I would say no, we shouldn't.

> I've been working with Ganesh on editing the Architecture Draft.
> Seems to me that this is an issue which needs more discussion.
> Here's my thoughts on it:

>  - If a network element (switch or router) understands things like
>    MPLS, it makes sense to let it use that understanding in creating
>    flows.

Maybe, but MPLS is just one of many possible encapsulations for IP
packets.  I don't think MPLS-specific attributes should be treated any
differently from e.g. attributes that are specific to ATM, Ethernet,
Frame Relay, POS.  This would be a somewhat open-ended endeavour, so
I'd like to keep this out of the base IPFIX standards.

Just defined MPLS-specific IPFIX attributes in a specific-lower-layer
extension to IPFIX.  There can be other extensions for Ethernet etc.

>  - On the other hand, we have to define a 'base specification,'
>    i.e. what's the minimum set of packet attributes an IPFIX
>    exporter MUST support if it claims to be IPFIX-conformant?

>  - It's very difficult to decide where to draw the line on this.
>    MPLS is clear enough, but how about other encapsulations,
>    e.g. IP-in-IP, GRE, etc.?  Application information, e.g. in
>    RTP header fields [RFC1889], raises even more questions.

> How about the following as a minimal definition for the header
> fields which can define a flow?  (This is one of three list items in
> the current Architecture Draft).

> * One or more header fields of the actual packet, e.g. destination
>    IP address, or one of the fields in the packet's encapsulation
>    header, e.g. label for MPLS, tunnel end-points for IP-in-IP, etc.

> The IPFIX Information Model could specify encapsulation-header-based
> attributes as they seem neccessary and/or useful ...

Yes, but I suggest to keep specific lower layers out of the base
document set.
-- 
Simon.

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 27 02:32:39 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19141
	for <ipfix-archive@lists.ietf.org>; Fri, 27 Jun 2003 02:32:39 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19VmPj-0003nH-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 27 Jun 2003 01:08:51 -0500
Received: from cms1.etri.re.kr ([129.254.16.11])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19VmPh-0003n6-00
	for ipfix@net.doit.wisc.edu; Fri, 27 Jun 2003 01:08:49 -0500
Received: from etri.re.kr (TASSAJARA [129.254.70.152]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id NAHCTLHR; Fri, 27 Jun 2003 15:08:38 +0900
Message-ID: <3EFBDF6E.EFAB6BEE@etri.re.kr>
Date: Fri, 27 Jun 2003 15:08:46 +0900
From: Changhoon Kim <kimch@etri.re.kr>
Organization: ETRI
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: David Diep <diep@sdl.hitachi.co.jp>
CC: ipfix@net.doit.wisc.edu, choits@etri.re.kr
Subject: Re: [ipfix] Per-packet record proposal (pktId)
References: <003001c33bcd$9b9ae520$46049085@hitachiialx8tm>
Content-Type: multipart/alternative;
 boundary="------------0936AC488C1261CD067D9C9C"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


--------------0936AC488C1261CD067D9C9C
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi David,

Your point is correct.
However, the purpose of the pktId is not for identifying a packet in a
flow-locally (or globally) unique way,
but conveying the identification value as it is originally marked in the
packet.
If majority of the group view that we need to have another element for
the flow-local identificaion purpose,
defining a new element is always welcomed.

IPv4 specific issues. Yes, I only considered IPv4 while I was writing
the 00 draft.
I also hope that the group will improve the draft so that it reflects
the considerations for IPv6.

Best,

- Chang

> If you use IP header identification field for any flow this is
> problematic because this value is unique for a source-destination pair
> and protocol for the time the datagram will be active in the internet
> system. To my understanding the flow definition of IPFIX is much more
> flexible (This definition covers the range from a flow containing all
> packets observed at a network interface to a flow consisting of just a
> single packet from draft-ietf-ipfix-protocol-00.txt). Consequently
> your probability of collision may be high depending on the flow type
> that you consider, so in the general case, you will not be able to
> conclude anything about rooting loop in case you have two times the
> same id for a given flow.
> Last point, you're using an IPv4 specific feature that you can't
> extend directly to IPv6 traffic…
>
> Regards,
>
> David
>
> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On
> Behalf Of Changhoon Kim
> Sent: Thursday, June 26, 2003 6:05 PM
> To: David Diep
> Cc: ipfix@net.doit.wisc.edu; choits@etri.re.kr
> Subject: Re: [ipfix] Per-packet record proposal (pktId)
>
> Hi David,
>
> Thank you for your interest and comment.
>
> We intended to use the pktId element to contain the 16-bit
> identification value in the IP header.
> The identification is a host-local value and incremented by one each
> time a datagram is sent by the src host.
> The field plays an important role for reassemblying packet fragments
> and for detecting some routing anomalies;
> when two packets within a flow have the same id (with different
> timestamps), it guarantees that there exists a routing loop on the
> flow's path. We, thus, see that the pktId element should contain the
> value of the identification field without additional processing.
>
> If the consensus of the group is turned out to define another element
> for identifying every packet in a globally unique way, then we may be
> able to add another element for that purpose.
>
> Best,
>
> - Chang
>
> David Diep wrote:
>
>> Hi,
>> The per-packet information could be used in QoS passive measurement
>> when the meter needs to export a list of packet identifier
>> (packetID) and the associated timestamps. In order to reduce the
>> packetID collision a classical scheme is to generate the packetID
>> based on packet header and packet payload and then to use CRC-32
>> function. In the presented document the pktId type is defined as
>> short type. I think that in order to be used with a low collision
>> probability as the packetID, the type of the pktId parameter should
>> be based at least on a 32-bits type.
>> Best Regards,
>> David Diep
>>

--------------0936AC488C1261CD067D9C9C
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body link="#0000FF" vlink="#800080" lang="EN-US" style="tab-interval:.5in">
Hi David,
<p>Your point is correct.
<br>However, the purpose of the pktId is not for identifying a packet in
a flow-locally (or globally) unique way,
<br>but conveying the identification value as it is originally marked in
the packet.
<br>If majority of the group view that we need to have another element
for the flow-local identificaion purpose,
<br>defining a new element is always welcomed.
<p>IPv4 specific issues. Yes, I only considered IPv4 while I was writing
the 00 draft.
<br>I also hope that the group will improve the draft so that it reflects
the considerations for IPv6.
<p>Best,
<p>- Chang
<blockquote TYPE=CITE>
<div class=Section1>
<div class="MsoNormal"><font face="Arial"><font color="#000080"><font size=-1>If
you use IP header identification field for any flow this is problematic
because this value is unique for a source-destination pair and protocol
for the time the datagram will be active in the internet system. To my
understanding the flow definition of IPFIX is much more flexible (This
definition covers the range from a flow containing all packets observed
at a network interface to a flow consisting of just a single packet from
draft-ietf-ipfix-protocol-00.txt). Consequently your probability of collision
may be high depending on the flow type that you consider, so in the general
case, you will not be able to conclude anything about rooting loop in case
you have two times the same id for a given flow.</font></font></font></div>

<div class="MsoNormal"><o:p></o:p></span></div>

<div class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><font face="Arial"><font color="#000080"><font size=-1>Last
point, you're using an IPv4 specific feature that you can't extend directly
to IPv6 traffic…</font></font></font><o:p></o:p></span></div>

<div class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p></o:p></span></div>


<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><font face="Arial"><font color="#000080"><font size=-1>Regards,</font></font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><font face="Arial"><font color="#000080"><font size=-1>David</font></font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p></o:p></span>

<p class="MsoNormal" style="margin-left:.5in"><span 
style='font-size:10.0pt;font-family:Tahoma;mso-fareast-font-family:SimSun;
mso-fareast-language:ZH-CN'><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><span style='font-weight:bold'><font face="Tahoma"><font size=-1><b>From:</span></b>
majordomo listserver [<A HREF="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</A>]&nbsp;<span style='font-weight:bold'><b>On
Behalf Of&nbsp;</span></b>Changhoon Kim</font></font>
<br><span style='font-weight:bold'><font face="Tahoma"><font size=-1><b>Sent:</span></b>
Thursday, June 26, 2003 6:05 PM</font></font>
<br><span style='font-weight:bold'><font face="Tahoma"><font size=-1><b>To:</span></b>
David Diep</font></font>
<br><span style='font-weight:bold'><font face="Tahoma"><font size=-1><b>Cc:</span></b>
ipfix@net.doit.wisc.edu; choits@etri.re.kr</font></font>
<br><span style='font-weight:bold'><font face="Tahoma"><font size=-1><b>Subject:</span></b>
Re: [ipfix] Per-packet record proposal (pktId)</font></font></span>

<p class="MsoNormal" style="margin-left:.5in"><span 
style='font-size:12.0pt'><o:p></o:p></span>

<p class="MsoNormal" style="margin-left:.5in"><span 
style='font-size:12.0pt'><font face="Gulim"><font size=+0>Hi
David,&nbsp;</font></font><o:p></o:p></span>

<p style="margin-left:.5in"><span style='font-size:
12.0pt'><font face="Gulim"><font size=+0>Thank
you for your interest and comment.&nbsp;</font></font><o:p></o:p></span>

<p style="margin-left:.5in"><span style='font-size:
12.0pt'><font face="Gulim"><font size=+0>We
intended to use the pktId element to contain the 16-bit identification
value in the IP header.</font></font>
<br><font face="Gulim"><font size=+0>The identification is a host-local
value and incremented by one each time a datagram is sent by the src host.</font></font>
<br><font face="Gulim"><font size=+0>The field plays an important role
for reassemblying packet fragments and for detecting some routing anomalies;</font></font>
<br><font face="Gulim"><font size=+0>when two packets within a flow have
the same id (with different timestamps), it guarantees that there exists
a routing loop on the flow's path. We, thus, see that the pktId element
should contain the value of the identification field without additional
processing.&nbsp;</font></font><o:p></o:p></span>

<p style="margin-left:.5in"><span style='font-size:
12.0pt'><font face="Gulim"><font size=+0>If
the consensus of the group is turned out to define another element for
identifying every packet in a globally unique way, then we may be able
to add another element for that purpose.&nbsp;</font></font><o:p></o:p></span>

<p style="margin-left:.5in"><span style='font-size:
12.0pt'><font face="Gulim"><font size=+0>Best,&nbsp;</font></font><o:p></o:p></span>

<p style="margin-left:.5in"><span style='font-size:
12.0pt'><font face="Gulim"><font size=+0>-
Chang</font></font>
<br><o:p></o:p></span>

<p style="margin-left:.5in"><span style='font-size:
12.0pt'><font face="Gulim"><font size=+0>David
Diep wrote:&nbsp;</font></font><o:p></o:p></span>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' TYPE=CITE><!--[if gte mso 9]><xml>
 <u1:OfficeDocumentSettings>
  <u1:DoNotRelyOnCSS/>
 </u1:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <u2:WordDocument>
  <u2:SpellingState>Clean</u2:SpellingState>
  <u2:GrammarState>Clean</u2:GrammarState>
  <u2:DocumentKind>DocumentEmail</u2:DocumentKind>
  <u2:EnvelopeVis/>
  <u2:Compatibility>
   <u2:UseFELayout/>
  </u2:Compatibility>
  <u2:BrowserLevel>MicrosoftInternetExplorer4</u2:BrowserLevel>
 </u2:WordDocument>
</xml><![endif]-->
<div class="MsoNormal" style="margin-left:.5in"><span 
style='font-size:10.0pt;font-family:Arial;color:navy'><font face="Arial"><font color="#000080"><font size=-1>Hi,</font></font></font><u3:p></u3:p></span><o:p></o:p></div>

<div class="MsoNormal" style="margin-left:.5in"><span 
style='font-size:10.0pt;font-family:Arial;color:navy'><u3:p></u3:p><font face="Arial"><font color="#000080"><font size=-1>The
per-packet information could be used in QoS passive measurement when the
meter needs to export a list of packet identifier (packetID) and the associated
timestamps. In order to reduce the packetID collision a classical scheme
is to generate the packetID based on packet header and packet payload and
then to use CRC-32 function. In the presented document the pktId type is
defined as short type. I think that in order to be used with a low collision
probability as the packetID, the type of the pktId parameter should be
based at least on a 32-bits type.</font></font></font><u3:p></u3:p></span><o:p></o:p></div>

<div class="MsoNormal" style="margin-left:.5in"><span 
style='font-size:10.0pt;font-family:Arial;color:navy'><u3:p></u3:p><font face="Arial"><font color="#000080"><font size=-1>Best
Regards,</font></font></font><u3:p></u3:p></span><o:p></o:p></div>

<div class="MsoNormal" style="margin-left:.5in"><span 
style='font-size:10.0pt;font-family:Arial;color:navy'><u3:p></u3:p><font face="Arial"><font color="#000080"><font size=-1>David
Diep&nbsp;</font></font></font><u3:p></u3:p></span><o:p></o:p></div>
</blockquote>
</div>
</blockquote>

</body>
</html>

--------------0936AC488C1261CD067D9C9C--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 27 07:56:09 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23270
	for <ipfix-archive@lists.ietf.org>; Fri, 27 Jun 2003 07:56:08 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19VqsZ-0005BG-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 27 Jun 2003 05:54:55 -0500
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19VqsX-0005B5-00
	for ipfix@net.doit.wisc.edu; Fri, 27 Jun 2003 05:54:53 -0500
Received: from fokus.fraunhofer.de (dhcp210 [195.37.78.210])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id h5RAseQ26522;
	Fri, 27 Jun 2003 12:54:41 +0200 (MEST)
Message-ID: <3EFC226F.9020406@fokus.fraunhofer.de>
Date: Fri, 27 Jun 2003 12:54:39 +0200
From: Tanja Zseby <zseby@fokus.fraunhofer.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: de-de, de, en-us
MIME-Version: 1.0
To: Changhoon Kim <kimch@etri.re.kr>
CC: David Diep <diep@sdl.hitachi.co.jp>, ipfix@net.doit.wisc.edu,
        choits@etri.re.kr, Guido Pohl <pohl@fokus.fraunhofer.de>,
        Lutz Mark
 <mark@fokus.fraunhofer.de>,
        Carsten Schmoll
 <schmoll@fokus.fraunhofer.de>
Subject: Re: [ipfix] Per-packet record proposal (pktId)
References: <003001c33bcd$9b9ae520$46049085@hitachiialx8tm> <3EFBDF6E.EFAB6BEE@etri.re.kr>
Content-Type: multipart/mixed;
 boundary="------------060009040807050906080401"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.
--------------060009040807050906080401
Content-Type: multipart/alternative;
 boundary="------------000409040807070908070304"


--------------000409040807070908070304
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

  Hi,

we support the idea to integrate a field for a packet ID for multipoint 
QoS measurements.
Maybe you can have a look at a paper that we presented a few month ago 
on how to use IPFIX/netflow9 for passive one-way delay measurements:
http://www.ist-intermon.org/workshop/papers/03_03_powd-netflow9.pdf
We also started a separate draft on this (see attachement, not yet 
submitted) for exporting pktIDs and per packet timestamps with IPFIX .

Regards
Tanja


Changhoon Kim wrote:

> Hi David,
>
> Your point is correct.
> However, the purpose of the pktId is not for identifying a packet in a 
> flow-locally (or globally) unique way,
> but conveying the identification value as it is originally marked in 
> the packet.
> If majority of the group view that we need to have another element for 
> the flow-local identificaion purpose,
> defining a new element is always welcomed.
>
> IPv4 specific issues. Yes, I only considered IPv4 while I was writing 
> the 00 draft.
> I also hope that the group will improve the draft so that it reflects 
> the considerations for IPv6.
>
> Best,
>
> - Chang
>
>> If you use IP header identification field for any flow this is 
>> problematic because this value is unique for a source-destination 
>> pair and protocol for the time the datagram will be active in the 
>> internet system. To my understanding the flow definition of IPFIX is 
>> much more flexible (This definition covers the range from a flow 
>> containing all packets observed at a network interface to a flow 
>> consisting of just a single packet from 
>> draft-ietf-ipfix-protocol-00.txt). Consequently your probability of 
>> collision may be high depending on the flow type that you consider, 
>> so in the general case, you will not be able to conclude anything 
>> about rooting loop in case you have two times the same id for a given 
>> flow.
>> Last point, you're using an IPv4 specific feature that you can't 
>> extend directly to IPv6 traffic...
>>
>> Regards,
>>
>> David
>>
>> -----Original Message-----
>> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On 
>> Behalf Of Changhoon Kim
>> Sent: Thursday, June 26, 2003 6:05 PM
>> To: David Diep
>> Cc: ipfix@net.doit.wisc.edu; choits@etri.re.kr
>> Subject: Re: [ipfix] Per-packet record proposal (pktId)
>>
>> Hi David, 
>>
>> Thank you for your interest and comment. 
>>
>> We intended to use the pktId element to contain the 16-bit 
>> identification value in the IP header.
>> The identification is a host-local value and incremented by one each 
>> time a datagram is sent by the src host.
>> The field plays an important role for reassemblying packet fragments 
>> and for detecting some routing anomalies;
>> when two packets within a flow have the same id (with different 
>> timestamps), it guarantees that there exists a routing loop on the 
>> flow's path. We, thus, see that the pktId element should contain the 
>> value of the identification field without additional processing. 
>>
>> If the consensus of the group is turned out to define another element 
>> for identifying every packet in a globally unique way, then we may be 
>> able to add another element for that purpose. 
>>
>> Best, 
>>
>> - Chang
>>
>> David Diep wrote: 
>>
>>> Hi,
>>> The per-packet information could be used in QoS passive measurement 
>>> when the meter needs to export a list of packet identifier 
>>> (packetID) and the associated timestamps. In order to reduce the 
>>> packetID collision a classical scheme is to generate the packetID 
>>> based on packet header and packet payload and then to use CRC-32 
>>> function. In the presented document the pktId type is defined as 
>>> short type. I think that in order to be used with a low collision 
>>> probability as the packetID, the type of the pktId parameter should 
>>> be based at least on a 32-bits type.
>>> Best Regards,
>>> David Diep 
>>

-- 
Dipl.-Ing. Tanja Zseby			    	      	
Fraunhofer Institute FOKUS			Email: zseby@fokus.fraunhofer.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)
--------------------------------------------------------------------------------------



--------------000409040807070908070304
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
                                 Hi,<br>
   <br>
   we support the idea to integrate a field for a packet ID for multipoint
QoS measurements.<br>
   Maybe you can have a look at a paper that we presented a few month ago 
on  how to use IPFIX/netflow9 for passive one-way delay measurements:<br>
   <a class="moz-txt-link-freetext"
 href="http://www.ist-intermon.org/workshop/papers/03_03_powd-netflow9.pdf">http://www.ist-intermon.org/workshop/papers/03_03_powd-netflow9.pdf</a><br>
    We also started a separate draft on this (see attachement, not yet submitted) 
for exporting pktIDs and per packet timestamps with IPFIX . <br>
 <br>
 Regards<br>
 Tanja<br>
 <br>
 <br>
Changhoon Kim wrote:<br>
<blockquote type="cite" cite="mid3EFBDF6E.EFAB6BEE@etri.re.kr">   Hi David, 
  <p>Your point is correct. <br>
However, the purpose of the pktId is not for identifying a packet in a flow-locally
(or globally) unique way, <br>
but conveying the identification value as it is originally marked in the
packet. <br>
If majority of the group view that we need to have another element for the
flow-local identificaion purpose, <br>
defining a new element is always welcomed. </p>
  <p>IPv4 specific issues. Yes, I only considered IPv4 while I was writing 
the 00 draft. <br>
I also hope that the group will improve the draft so that it reflects the
considerations for IPv6. </p>
  <p>Best, </p>
  <p>- Chang </p>
  <blockquote type="CITE"> 
    <div class="Section1"> 
    <div class="MsoNormal"><font face="Arial"><font color="#000080"><font
 size="-1">If you use IP header identification field for any flow this is
problematic because this value is unique for a source-destination pair and
protocol for the time the datagram will be active in the internet system.
To my understanding the flow definition of IPFIX is much more flexible (This 
definition covers the range from a flow containing all packets observed at
a network interface to a flow consisting of just a single packet from draft-ietf-ipfix-protocol-00.txt).
Consequently your probability of collision may be high depending on the flow
type that you consider, so in the general case, you will not be able to conclude
anything about rooting loop in case you have two times the same id for a
given flow.</font></font></font></div>
  
    <div class="MsoNormal"><o:p></o:p></div>
  
    <div class="MsoNormal"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><font
 face="Arial"><font color="#000080"><font size="-1">Last point, you're using
an IPv4 specific feature that you can't extend directly to IPv6 traffic&#8230;</font></font></font><o:p></o:p></span></div>
  
    <div class="MsoNormal"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p></o:p></span></div>
   
    <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><font
 face="Arial"><font color="#000080"><font size="-1">Regards,</font></font></font><o:p></o:p></span> 
 </p>
    <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p></o:p></span> 
 </p>
    <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><font
 face="Arial"><font color="#000080"><font size="-1">David</font></font></font><o:p></o:p></span> 
 </p>
    <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p></o:p></span> 
 </p>
    <p class="MsoNormal" style="margin-left: 0.5in;"><span
 style="font-size: 10pt; font-family: Tahoma;"><font face="Tahoma"><font
 size="-1">-----Original Message-----</font></font> <br>
    <span style="font-weight: bold;"><font face="Tahoma"><font size="-1"><b>From:</b></font></font></span> 
    <font face="Tahoma"><font size="-1">majordomo listserver [<a
 href="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</a>]&nbsp;<span
 style="font-weight: bold;"><b>On Behalf Of&nbsp;</b></span>Changhoon Kim</font></font> 
    <br>
    <span style="font-weight: bold;"><font face="Tahoma"><font size="-1"><b>Sent:</b></font></font></span> 
    <font face="Tahoma"><font size="-1">Thursday, June 26, 2003 6:05 PM</font></font> 
    <br>
    <span style="font-weight: bold;"><font face="Tahoma"><font size="-1"><b>To:</b></font></font></span> 
    <font face="Tahoma"><font size="-1">David Diep</font></font> <br>
    <span style="font-weight: bold;"><font face="Tahoma"><font size="-1"><b>Cc:</b></font></font></span> 
    <font face="Tahoma"><font size="-1"><a class="moz-txt-link-abbreviated" href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a>; <a class="moz-txt-link-abbreviated" href="mailto:choits@etri.re.kr">choits@etri.re.kr</a></font></font> 
    <br>
    <span style="font-weight: bold;"><font face="Tahoma"><font size="-1"><b>Subject:</b></font></font></span> 
    <font face="Tahoma"><font size="-1">Re: [ipfix] Per-packet record proposal
(pktId)</font></font></span>  </p>
    <p class="MsoNormal" style="margin-left: 0.5in;"><span
 style="font-size: 12pt;"><o:p></o:p></span>  </p>
    <p class="MsoNormal" style="margin-left: 0.5in;"><span
 style="font-size: 12pt;"><font face="Gulim"><font size="+0">Hi David,&nbsp;</font></font><o:p></o:p></span> 
 </p>
    <p style="margin-left: 0.5in;"><span style="font-size: 12pt;"><font
 face="Gulim"><font size="+0">Thank you for your interest and comment.&nbsp;</font></font><o:p></o:p></span> 
 </p>
    <p style="margin-left: 0.5in;"><span style="font-size: 12pt;"><font
 face="Gulim"><font size="+0">We intended to use the pktId element to contain
the 16-bit identification value in the IP header.</font></font> <br>
    <font face="Gulim"><font size="+0">The identification is a host-local 
value and incremented by one each time a datagram is sent by the src host.</font></font> 
    <br>
    <font face="Gulim"><font size="+0">The field plays an important role for
reassemblying packet fragments and for detecting some routing anomalies;</font></font> 
    <br>
    <font face="Gulim"><font size="+0">when two packets within a flow have 
the same id (with different timestamps), it guarantees that there exists a
routing loop on the flow's path. We, thus, see that the pktId element should
contain the value of the identification field without additional processing.&nbsp;</font></font><o:p></o:p></span> 
 </p>
    <p style="margin-left: 0.5in;"><span style="font-size: 12pt;"><font
 face="Gulim"><font size="+0">If the consensus of the group is turned out
to define another element for identifying every packet in a globally unique
way, then we may be able to add another element for that purpose.&nbsp;</font></font><o:p></o:p></span> 
 </p>
    <p style="margin-left: 0.5in;"><span style="font-size: 12pt;"><font
 face="Gulim"><font size="+0">Best,&nbsp;</font></font><o:p></o:p></span>  </p>
    <p style="margin-left: 0.5in;"><span style="font-size: 12pt;"><font
 face="Gulim"><font size="+0">- Chang</font></font> <br>
    <o:p></o:p></span>  </p>
    <p style="margin-left: 0.5in;"><span style="font-size: 12pt;"><font
 face="Gulim"><font size="+0">David Diep wrote:&nbsp;</font></font><o:p></o:p></span> 
    </p>
    <blockquote style="margin-top: 5pt; margin-bottom: 5pt;" type="CITE"><!--[if gte mso 9]><xml>
 <u1:OfficeDocumentSettings>
  <u1:DoNotRelyOnCSS/>
 </u1:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <u2:WordDocument>
  <u2:SpellingState>Clean</u2:SpellingState>
  <u2:GrammarState>Clean</u2:GrammarState>
  <u2:DocumentKind>DocumentEmail</u2:DocumentKind>
  <u2:EnvelopeVis/>
  <u2:Compatibility>
   <u2:UseFELayout/>
  </u2:Compatibility>
  <u2:BrowserLevel>MicrosoftInternetExplorer4</u2:BrowserLevel>
 </u2:WordDocument>
</xml><![endif]--> 
      <div class="MsoNormal" style="margin-left: 0.5in;"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><font
 face="Arial"><font color="#000080"><font size="-1">Hi,</font></font></font><u3:p></u3:p></span><o:p></o:p></div>
  
      <div class="MsoNormal" style="margin-left: 0.5in;"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><u3:p></u3:p><font
 face="Arial"><font color="#000080"><font size="-1">The per-packet information
could be used in QoS passive measurement when the meter needs to export a
list of packet identifier (packetID) and the associated timestamps. In order
to reduce the packetID collision a classical scheme is to generate the packetID
based on packet header and packet payload and then to use CRC-32 function.
In the presented document the pktId type is defined as short type. I think
that in order to be used with a low collision probability as the packetID,
the type of the pktId parameter should be based at least on a 32-bits type.</font></font></font><u3:p></u3:p></span><o:p></o:p></div>
  
      <div class="MsoNormal" style="margin-left: 0.5in;"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><u3:p></u3:p><font
 face="Arial"><font color="#000080"><font size="-1">Best Regards,</font></font></font><u3:p></u3:p></span><o:p></o:p></div>
  
      <div class="MsoNormal" style="margin-left: 0.5in;"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><u3:p></u3:p><font
 face="Arial"><font color="#000080"><font size="-1">David Diep&nbsp;</font></font></font><u3:p></u3:p></span><o:p></o:p></div>
 </blockquote>
 </div>
 </blockquote>
  </blockquote>
<br>
<pre class="moz-signature" cols="$mailwrapcol">-- 
Dipl.-Ing. Tanja Zseby			    	      	
Fraunhofer Institute FOKUS			Email: <a class="moz-txt-link-abbreviated" href="mailto:zseby@fokus.fraunhofer.de">zseby@fokus.fraunhofer.de</a>	
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)
--------------------------------------------------------------------------------------
</pre>
<br>
</body>
</html>

--------------000409040807070908070304--

--------------060009040807050906080401
Content-Type: text/plain;
 name="draft-pohl-pktid-00.txt"
Content-Disposition: inline;
 filename="draft-pohl-pktid-00.txt"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub.fokus.fraunhofer.de id h5RAseQ26522
Content-Transfer-Encoding: quoted-printable


 =20
                                                                        =20
 Internet Draft                                                  G. Pohl=20
 Document: <draft-pohl-pktid-00.txt>                    Fraunhofer FOKUS=20
 Expires: January 2004                                           L. Mark=20
                                                        Fraunhofer FOKUS=20
                                                              C. Schmoll=20
                                                        Fraunhofer FOKUS=20
                                                                T. Zseby=20
                                                        Fraunhofer FOKUS=20
                                                              June  2003=20
 =20
 =20
        IPFIX Export of packet information for QoS Meaurements=20
 =20
 Status of this Memo=20
 =20
    This document is an Internet-Draft and is in full conformance=20
    with all provisions of Section 10 of RFC2026. =20
    =20
    Internet-Drafts are working documents of the Internet=20
    Engineering Task Force (IETF), its areas, and its working=20
    groups. Note that other groups may also distribute working=20
    documents as Internet-Drafts. Internet-Drafts are draft=20
    documents valid for a maximum of six months and may be updated,=20
    replaced, or obsoleted by other documents at any time. It is=20
    inappropriate to use Internet-Drafts as reference material or to=20
    cite them other than as "work in progress." =20
    =20
    The list of current Internet-Drafts can be accessed at=20
    http://www.ietf.org/ietf/1id-abstracts.txt =20
    =20
    The list of Internet-Draft Shadow Directories can be accessed at=20
    http://www.ietf.org/shadow.html.=20
    =20
 Abstract=20
    =20
    This document describes an extension for the IP Flow Information=20
    Export (IPFIX) protocol that allows to export packet information=20
    for QoS measurements with IPFIX. =20
    The main idea is to export two types of records per flow. One=20
    type, that consists of the usual flow information plus a unique=20
    flow id. And a second type of record, that consists of this flow=20
    id and the packet data. The flow id is used to associate the=20
    packet data to the corresponding flow.=20
    =20
 =20
 Table of Contents=20
 =20
    1.   Introduction.................................................1=20
    2.   Terminology..................................................2=20
    3.   General Problem Statement....................................2=20
    4.   Export of Packet Ids, Timestamps, and Flow Information.......4=20
    5.   Export OWD data..............................................4=20
    6.   Export and evaluation considerations.........................5=20
    7.   Security Considerations......................................5=20
    8.   References...................................................5=20
    9.   Author's Addresses...........................................6=20
    10.  Full Copyright Statement.....................................6=20
 =20
 1. Introduction=20
    =20
    In the scope of passive QoS Measurements there is often the need=20
    to exchange and export measurement data in a finer granularity=20
    then per flows. As an example we take passive one-way delay=20
    measurement and demonstrate the need for per information export=20
 =20
 Mark, Pohl, Schmoll, Zseby Expires January 2004            [Page 1]=20
=0C
        IPFIX Export of packet information for QoS Meaurements=20

    on a per-packet basis. Instead of exporting flow related=20
    information per-packet and introducing a high degree of=20
    redundancy we show how packet information and flow information=20
    can be efficiently be exported and related.=20
    =20
 =20
 2. Terminology=20
 =20
    Collecting Process=20
         The collecting process receives records of flow or packet=20
         information. The data is stored for later processing (by=20
         the calculation process)=20
    =20
    Exporting Process=20
         The exporting processes send flow and packet records to the=20
         collecting processes. The records are generated by the=20
         measurement process.=20
    =20
    Filtering =20
         Filtering selects a subset of packets by applying=20
         deterministic functions on parts of the packet content like=20
         header fields or parts of the payload. A filtering process=20
         needs to process the packet (look at packet header and/or=20
         payload) in order to make the selection decision.=20
    =20
    Measurement Device=20
         A measurement device has access to at least one observation=20
         point. It is hosting at least one measurement process and=20
         one export process.=20
    =20
    Metering/Measurement Process =20
         The measurement process generates records of packet and=20
         flow information. Packets passing the observation point are=20
         captured, time stamped, filtered and classified. The=20
         measurement process calculates the packet Ids.=20
         =20
    Passive One-Way-Delay Measurement=20
         abbreviated: POWD Measurement=20
    =20
    Add text here ;-)=20
    =20
 =20
 3. General Problem Statement=20
    =20
    In [Clai03] the IPFIX working group defined an exporting=20
    protocol for measurement data and flow information export.=20
    =20
    The initial purpose of that protocol is to exchange information=20
    about network traffic flows. In this scope a flow is defined by=20
    a handful of key attributes (source/destination address,=20
    source/destination port, Layer3 Protocol Type, TOS/DSCP byte,=20
    interface of the flow exporting network element).=20
    =20
    In the initial sense, a flow aggregates a number of packets with=20
    common attributes. However, for a number of measurements=20
    (metrics) there is a need to export per-packet data. As a case=20
    in point we mention passive One-Way-Delay measurements. In order=20
    to acquire a path delay this way a couple of measurement points=20
    are set up - one at either end of the path under examination.=20
    Both measurement points will capture and furniture packets with=20
    timestamps and generate an identifier for identifying a packet=20
    passing both measurement points. Each measurement point will=20
    export its measurement data (trace) to a collecting process=20
    where the traces are correlated based on the packet identifiers=20
    and timestamps and where finally the delay is calculated as a=20
    difference of two timestamps of a packet pair. =20
                                                       =20
 Mark, Pohl, Schmoll, Zseby        Expires January 2004        [Page 2]=20
=0C
        IPFIX Export of packet information for QoS Meaurements=20

    =20
    It is clear that one could consider a single packet as a special=20
    case of a flow. This procedure has consequences that conflict=20
    with the efficiency of the exporting procedure. When many=20
    packets belong to the same flow, i.e. they share common=20
    attributes; these attributes would have to be exported on a per-
    packet basis together with a different packet ID each time=20
    although the information is redundant.=20
    =20
    There are cases where it is desirable to keep flow information=20
    along with the per-packet information, that is, when analyzing=20
    packet characteristics while regarding flows. The upper part of=20
    Figure 1 shows both packet data (id and timestamp) and=20
    information (source and destination address) that is relevant=20
    for the flow of the packet belongs to. Undoubtedly, the flow=20
    information introduces a huge amount of redundancy, as it exists=20
    for every packet. Figure 1 depicts three packets that affiliate=20
    to flow A and one packet that belongs to flow B, respectively.=20
    Reducing the redundancy is a known problem in relational data=20
    base design. The lower part of Figure 1 shows the idea to=20
    separate the flow from packet information. In order to maintain=20
    the relation between Packet Properties and Flow Properties we=20
    introduce indices (idxA and idxB) for the Flow Properties, these=20
    are unique concerning all Flow Property entries. The purpose of=20
    the indices is to serve as =93primary key=94 that identifies rows of=20
    the Flow Properties. The rows are then referenced by the Packet=20
    Properties by using the appropriate index.=20
    =20
    =20
    one packet flows=20
    +------+------+------------+---------+=20
    | srcA | dstA | packet id1 | tstamp1 |=20
    +------+------+------------+---------+=20
    | srcA | dstA | packet id2 | tstamp2 |=20
    +------+------+------------+---------+=20
    | srcB | dstB | packet id3 | tstamp3 |=20
    +------+------+------------+---------+=20
    | srcA | dstA | packet id4 | tstamp4 |=20
    +------+------+------------+---------+=20
    =20
            separating flow information and packet information=20
            reduces redundancy=20
                                  Packet Properties=20
                                 +-----+------------+---------+=20
    Flow Properties              >idxA | packet id1 | tstamp1 |=20
    +------+------+-----+        +-----+------------+---------+=20
    | srcA | dstA |idxA <        >idxA | packet id2 | tstamp2 |=20
    +------+------+-----+        +-----+------------+---------+=20
    | srcB | dstB |idxB <-------->idxB | packet id3 | tstamp3 |=20
    +------+------+-----+        +-----+------------+---------+=20
                                 >idxB | packet id4 | tstamp4 |=20
                                 +-----+------------+---------+=20
    =20
             exemplarily, the linkage of one packet (id3) and=20
             flow B (srcB, dstB, idxB) is explicitly drawn=20
    =20
    =20
    Figure 1: Flow information and packet information=20
    =20
    =20
    In the following paragraphs we propose how to use IPFIX protocol=20
    efficiently for exporting packet flow information and per-packet=20
    information for OWD computation.=20
    =20
    =20

                                                       =20
 Mark, Pohl, Schmoll, Zseby        Expires January 2004        [Page 3]=20
=0C
        IPFIX Export of packet information for QoS Meaurements=20

 4. Export of Packet Ids, Timestamps, and Flow Information=20
    =20
    The IPFIX protocol is template based as NetFlow version 9. For a=20
    complete desciption of features of IPFIX refer to [Clai03]. Only=20
    that much, templates define the structure of data to be=20
    exported, this includes describing data fields to be exported=20
    together with its type and meaning. =20
    =20
    For Measurement Process Results we define two different template=20
    records, namely Packet Properties and Flow Properties.=20
    =20
    As indicated in Figure 2, the Flow Properties template defines=20
    the attributes for a flow; exemplarily IP source and destination=20
    address. The important field is the Flow Index Field. As we will=20
    explain the Flow Index will allow packet records to reference=20
    flow attributes. The Flow Index is a unique identifier for flow=20
    definitions. Subsequent data records (marked as R1 =85 Rk) define=20
    the actual flows. The FlowSet ID should indicate the special=20
    case of a Flow Property template. (FlowSet IDs 0 and 1 are=20
    already reserved for templates consisting of flow fields or=20
    option fields, respectively. However, the Collector must handle=20
    Flow Properties templates and their data records slightly=20
    different than usually.)=20
    =20
    The format for the information related to a single packet is=20
    defined in the Packet Properties template. This information is=20
    packet specific and normally not shared between many packets.=20
    Otherwise one would rather consider the information as flow=20
    related and therefore it has not to be exported for every=20
    packet.=20
    In the case of passive One-Way-Delay measurement, the Packet=20
    Properties template consists of at least Timestamp and Packet=20
    ID. Additionally, this template contains a Flow Index field. In=20
    packet records, the value of this field will contain one of the=20
    unique indices of the flow records exported before.=20
    =20
    =20
    +------------------+      +-------------------+=20
    | Template FlowSet |      | Template FlowSet  |  =20
    |                  |      |                   |  Description of =20
    | Flow Properties  |      | Packet Properties |  exported data       =
   =20
    +----------+-------+      +----------+--------+                 =20
    ...........|.........................|.............................  =
 =20
               |                         |                             =20
    +----------v-------+      +----------v--------+                      =
   =20
    | Data FlowSet     |      | Data FlowSet      |  exported data       =
    =20
    |                  <------+                   |  with references by =20
    | Flow Properties  |      | Packet Properties |  means of FlowIndex=20
    +------------------+      +-------------------+                 =20
                       =20
    Figure 2: Template FlowSet and Data FlowSet dependencies=20
    =20
 =20
 5. Export OWD data=20
    =20
    At the collection point packet records of two measurement points=20
    are gathered and correlated by means of the packet ID. The one-
    way delay is then calculated as stated earlier. The resulting=20
    delay data records are exported in a similar manner as the=20
    packet data have been. Especially, the linkage between delay=20
    data and flow information is represented with the discussed Flow=20
    Index fields. The OWD properties contain the Packet Pair ID=20
    (which is the packet ID of the two contributing packet records),=20
    a timestamp (which is the timestamp of the packet passing the=20
    reference monitor point) in order to reconstruct a time scale,=20
    the calculated delay value, and finally a flow index.=20
                                                       =20
 Mark, Pohl, Schmoll, Zseby        Expires January 2004        [Page 4]=20
=0C
        IPFIX Export of packet information for QoS Meaurements=20

    =20
 6. Export and evaluation considerations=20
    =20
    In order to use IPFIX protocol for packet and OWD data export we=20
    have to prepare several things. We must assign a new FlowSet ID=20
    from the range 2 to 255 for the Flow Properties templates.=20
    =20
    We have to introduce new Field Type definitions for=20
         Packet ID, Length N,=20
         Flow Index, Length 4,=20
         Timestamp, Length 8=20
    =20
    The size of the packet ID depends on the used generator function=20
    =96 in the case of a CRC32 the field size would be 4 bytes. The=20
    range for the flow indices should be reasonable large. We=20
    propose at least a 32-bit value, i.e. 4 bytes.=20
    =20
    We suggest using absolute timestamps with a resolution of=20
    nanoseconds and a width of 64-bit (signed). The origin will be=20
    Jan.1, 1970 as usual. (The range covers ~292 years. So we=20
    provoke a year-2262-Problem=85)=20
    The value for the one-way delay should be a 32-bit (signed)=20
    value, which covers ~2 seconds.=20
    =20
    A collecting instance must store the flow records of Flow=20
    Properties together with the Flow Indices. The flow records=20
    therefore should be handled like templates. A similar timeout=20
    and refresh mechanism as for templates themselves should be used=20
    for flow records too (refer to [Clai02]).=20
    =20
    The collector must be able to associate incoming packet records=20
    to flow records by matching the contained Flow Indices.=20
    For obvious reasons, the exporting process must send the=20
    appropriate defining flow records with the unique Flow Indices=20
    before it can send packet records that reference flow=20
    information by indices.=20
  =20
 =20
 7. Security Considerations=20
    =20
    For the proposed extension of the IPFIX protocol the same=20
    security considerations as for the IPFIX protocol apply. =20
    Nevertheless, additional privacy issues may be of concern if=20
    header or content information can be derived from packet IDs.=20
    =20
    TODO : extend section=20
 =20
    =20
 8. References=20
    =20
    [DuGG03]    Nick Duffield, Albert Greenberg, Matthias=20
                 Grossglauser, Jennifer Rexford: A Framework for=20
                 Passive Packet Measurement, Internet Draft <draft-
                 ietf-psamp-framework-02.txt>, March 2003=20
    =20
    [DuGr00]    Nick Duffield, Matthias Grossglauser: =93Trajectory=20
                 Sampling for Direct Traffic Observation=94,=20
                 Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden,=20
                 August 28 - September 1, 2000                     =20
    [QuZC03]    J. Quittek, et. Al: Requirements for IP Flow=20
                 Information Export, Internet Draft <draft-ietf-
                 ipfix-reqs-10.txt>, June 2003=20
    =20
    [GrDM98]    Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN,=20
                 Jed MARTENS, John G. CLEARY: Nonintrusive and=20
                 Accurate Measurement of Unidirectional Delay and=20
                                                       =20
 Mark, Pohl, Schmoll, Zseby        Expires January 2004        [Page 5]=20
=0C
        IPFIX Export of packet information for QoS Meaurements=20

                 Delay Variation on the Internet, INET'98, Geneva,=20
                 Switzerland, July 21-24, 1998=20
    =20
    [ZsZC01]    T. Zseby, S. Zander, G. Carle: Evalutation of=20
                 building blocks for passive one-way-delay=20
                 measurements, PAM2001, Amsterdam, April 23-24, 2001=20
    =20
    [TPBC03]    T. Tseby, R. Penno, N. Brownly, B. Claise: =20
                 IPFIX Applicability, Internet Draft <draft-ietf-
                 ipfix-as-00.txt>, June 2003=20
    =20
    [Clai03]    Benoit Claise: IPFIX Protocol Specification,=20
                 Internet Draft <draft-ietf-ipfix-protocol-00.txt>,=20
                 June 2003=20
    =20
 9. Author's Addresses=20
    =20
        Tanja Zseby =20
        Fraunhofer Institute for Open Communication Systems =20
        Kaiserin-Augusta-Allee 31 =20
        10589 Berlin =20
        Germany =20
        Phone: +49-30-34 63 7153 =20
        Fax:   +49-30-34 53 8153 =20
        Email: zseby@fokus.fraunhofer.de=20
    =20
        Lutz Mark =20
        Fraunhofer Institute for Open Communication Systems =20
        Kaiserin-Augusta-Allee 31 =20
        10589 Berlin =20
        Germany =20
        Phone: +49-30-34 63 7306 =20
        Fax:   +49-30-34 53 8306 =20
        Email: mark@fokus.fraunhofer.de =20
         =20
        Guido Pohl =20
        Fraunhofer Institute for Open Communication Systems =20
        Kaiserin-Augusta-Allee 31 =20
        10589 Berlin =20
        Germany =20
        Phone: +49-30-34 63 7164 =20
        Fax:   +49-30-34 53 8164 =20
        Email: pohl@fokus.fraunhofer.de =20
    =20
        Carsten Schmoll=20
        Fraunhofer Institute for Open Communication Systems =20
        Kaiserin-Augusta-Allee 31 =20
        10589 Berlin =20
        Germany =20
        Phone: +49-30-34 63 7136 =20
        Fax:   +49-30-34 53 8136 =20
        Email: schmoll@fokus.fraunhofer.de =20
       =20
    =20
 10.=20
     Full Copyright Statement=20
 =20
    Copyright (C) The Internet Society (2002). All Rights Reserved.=20
    This document and translations of it may be copied and furnished=20
    to others, and derivative works that comment on or otherwise=20
    explain it or assist in its implementation may be prepared,=20
    copied, published and distributed, in whole or in part, without=20
    restriction of any kind, provided that the above copyright=20
    notice and this paragraph are included on all such copies and=20
    derivative works. However, this document itself may not be=20
    modified in any way, such as by removing the copyright notice or=20
    references to the Internet Society or other Internet=20
                                                       =20
 Mark, Pohl, Schmoll, Zseby        Expires January 2004        [Page 6]=20
=0C
        IPFIX Export of packet information for QoS Meaurements=20

    organizations, except as needed for the purpose of developing=20
    Internet standards in which case the procedures for copyrights=20
    defined in the Internet Standards process must be followed, or=20
    as required to translate it into languages other than=20
    English. =20
    =20
    The limited permissions granted above are perpetual and will not=20
    be revoked by the Internet Society or its successors or assigns.=20
    =20
    This document and the information contained herein is provided=20
    on an=20
    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET=20
    ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR=20
    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE=20
    OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY=20
    IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A=20
    PARTICULAR PURPOSE.=20
    =20
    =20















































                                                       =20
 Mark, Pohl, Schmoll, Zseby        Expires January 2004        [Page 7]=20
=0C
--------------060009040807050906080401--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 29 17:20:20 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08130
	for <ipfix-archive@lists.ietf.org>; Sun, 29 Jun 2003 17:20:19 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19WjBG-0000yQ-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 29 Jun 2003 15:53:50 -0500
Received: from dclient217-162-192-16.hispeed.ch ([217.162.192.16] helo=localhost)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19WjBF-0000yH-00
	for ipfix-reqs@net.doit.wisc.edu; Sun, 29 Jun 2003 15:53:49 -0500
Received: from leinen by localhost with local (Exim 3.36 #1 (Debian))
	id 19Wixx-0008QR-00; Sun, 29 Jun 2003 22:40:05 +0200
To: ipfix-reqs@net.doit.wisc.edu
Subject: [ipfix-reqs] Indicating Anonymization
References: <1D3D2C371FCBD947A7897FABBD3533A50295FFC2@xsun01.ptp.hp.com>
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPdz,@ttmwYVO7l`6OXXYR`
From: Simon Leinen <simon@limmat.switch.ch>
In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A50295FFC2@xsun01.ptp.hp.com>
Date: 29 Jun 2003 22:40:04 +0200
Message-ID: <877k74hb2z.fsf@limmat.switch.ch>
Lines: 80
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

While updating my protocol evaluation I-D, I found the requirements
I-D section on anonymization somewhat problematic.  I apologize
bringing this up so late in the process.

The current revision (-10) has the following to say about
anonymization:

  6.7.  Anonymization
  
     The exporting process MAY be capable of anonymizing source and
     destination IP addresses in flow data before exporting them. It
     MAY support anonymization of port numbers and other
     fields. Please note that anonymization is not originally an
     application requirement, but derived from general requirements
     for treatment of measured traffic data within a network.
  
     When anonymized flow data is exported, this MUST be clearly
     indicated to all receiving collecting processes, such that they
     can distinguish anonymized data from non-anonymized data.

Note that there is no single generally accepted method for anonymizing
flow export data (or even individual fields such as an IP address),
and different situations may require different levels of
anonymization.

Because of this, I think that it is not sufficient that the collector
be able to "distinguish anonymized data from non-anonymized data", but
it must also know the method and "degree" of anonymization.  This is
similar to sampling, where it is not sufficient to know whether there
is sampling going on or not, but one is also interested in sampling
parameters such as sampling method (e.g. pseudo-random,
packet/byte/time/flow-based) and parameters (e.g. sampling interval).

On the other hand, whether and how anonymization is performed will be
purely a matter of configuration of the exporting device, and will not
change during normal operation.  This is in contrast to sampling,
where the parameters may change to adapt to the offered load.  So one
could argue that it's not even necessary to report anonymization,
because of the general assumption that the collector can know the
static configuration of the exporting device by some other means.

If we agree that collectors can obtain the necessary knowledge about
the configuration of anonymization by other means, then I suggest the
following replacement text.  This is blatantly stolen from the current
text about sampling:

  6.7.  Anonymization

     The metering process MAY be capable of anonymizing source and
     destination IP addresses in flow data before exporting them. It
     MAY support anonymization of port numbers and other
     fields. Please note that anonymization is not originally an
     application requirement, but derived from general requirements
     for treatment of measured traffic data within a network.
     
     If anonymization is supported, the anonymization configuration
     MUST be well defined. The anonymization configuration includes
     the anonymization method and all its parameters.

However, if we really think that the anonymization configuration must
be conveyed to the collector through the IPFIX protocol, I would
suggest the following wording (also stolen from the text on sampling,
but from the part on what happens when the sampling configuration
changes during operation):

  6.7.  Anonymization

     The metering process MAY be capable of anonymizing source and
     destination IP addresses in flow data before exporting them. It
     MAY support anonymization of port numbers and other
     fields. Please note that anonymization is not originally an
     application requirement, but derived from general requirements
     for treatment of measured traffic data within a network.
     
     If anonymization is supported, the anonymization configuration
     MUST be indicated to the collector. The anonymization
     configuration includes the anonymization method and all its
     parameters.
-- 
Simon.

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 29 18:59:27 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10347
	for <ipfix-archive@lists.ietf.org>; Sun, 29 Jun 2003 18:59:27 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19Wl1Q-000478-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 29 Jun 2003 17:51:48 -0500
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19Wl1P-000471-00
	for ipfix-reqs@net.doit.wisc.edu; Sun, 29 Jun 2003 17:51:47 -0500
Received: from Givoly ([192.168.0.3])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h5TMxJL10707;
	Sun, 29 Jun 2003 15:59:19 -0700
From: "Tal Givoly" <givoly@xacct.com>
To: "Simon Leinen" <simon@limmat.switch.ch>, <ipfix-reqs@net.doit.wisc.edu>
Subject: RE: [ipfix-reqs] Indicating Anonymization
Date: Sun, 29 Jun 2003 15:51:42 -0700
Message-ID: <DLEIIIOHMNPJPNMKGEFDAEDKDLAA.givoly@xacct.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 IMO, Build 9.0.2416 (9.0.2910.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <877k74hb2z.fsf@limmat.switch.ch>
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Simon,

It may be that that anonymization is perhaps even more complex than this.

I assume that the original intent was that even without any form of
encryption, the legitimate collector, or any party eavesdropping on the
communication, would not be able to correlate individual user's usage back
to that user. However, any form of anonymization that is a 1-to-1 function
of the original address space, and is completely specified, implies that
anybody could go back and discover the true identity of the "anonymized"
user. This would clearly be the case if one knows the function applied to
anonymize the address, and it is a 1-to-1 function (because you may be
using, for instance, a 32-bit field to represent the "anonymized" IP
address). One would know the function, if as you suggest, the function
itself is completely specified.

Why should it be a 1-to-1 function, you may ask? Well, it is important that
the collector still be able to distinguish the identity of the individual
user sessions - although not necessarily the user itself. But it shouldn't
get mixed with other sessions.

Why should you use the same field type for the anonymized values? Well,
that's not mandatory - but it would make it possible for some tools that are
designed for operating on IP addresses, for instance, to operate on
"anonymized" IP addresses. This is not mandatory, but may be useful.

Now, anonymization at the device level does introduce another problem - any
system downstream from the collector may not be able to correlate back to
individual user session. Supposing, for instance, IP addresses are
dynamically assigned via DHCP or RADIUS (depending on access technology) -
then another source of information will actually have the user's identity
(be it MAC address for DHCP or user name/realm for RADIUS). It will also be
the source that allows for distinguishing two users sessions sharing the
same IP but at different times (from 9-10 user1 used IP1 while the same IP1
was used between 10:05 and 11 by user2). So any anonymization in the device
would prevent downstream systems from recognizing that different records
represent different users traffic altogether.

This raises the questions:
- Is anonymization requirement well-defined?
- Is it even an important requirement for IPFIX?

I don't recall that there was much discussion ever about this requirement.
Wouldn't encryption of the links to avoid eavesdropping serve most of the
intended purpose? Why do we require the devices to support this?

Tal

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Simon Leinen
Sent: Sunday, June 29, 2003 1:40 PM
To: ipfix-reqs@net.doit.wisc.edu
Subject: [ipfix-reqs] Indicating Anonymization


While updating my protocol evaluation I-D, I found the requirements
I-D section on anonymization somewhat problematic.  I apologize
bringing this up so late in the process.

The current revision (-10) has the following to say about
anonymization:

  6.7.  Anonymization

     The exporting process MAY be capable of anonymizing source and
     destination IP addresses in flow data before exporting them. It
     MAY support anonymization of port numbers and other
     fields. Please note that anonymization is not originally an
     application requirement, but derived from general requirements
     for treatment of measured traffic data within a network.

     When anonymized flow data is exported, this MUST be clearly
     indicated to all receiving collecting processes, such that they
     can distinguish anonymized data from non-anonymized data.

Note that there is no single generally accepted method for anonymizing
flow export data (or even individual fields such as an IP address),
and different situations may require different levels of
anonymization.

Because of this, I think that it is not sufficient that the collector
be able to "distinguish anonymized data from non-anonymized data", but
it must also know the method and "degree" of anonymization.  This is
similar to sampling, where it is not sufficient to know whether there
is sampling going on or not, but one is also interested in sampling
parameters such as sampling method (e.g. pseudo-random,
packet/byte/time/flow-based) and parameters (e.g. sampling interval).

On the other hand, whether and how anonymization is performed will be
purely a matter of configuration of the exporting device, and will not
change during normal operation.  This is in contrast to sampling,
where the parameters may change to adapt to the offered load.  So one
could argue that it's not even necessary to report anonymization,
because of the general assumption that the collector can know the
static configuration of the exporting device by some other means.

If we agree that collectors can obtain the necessary knowledge about
the configuration of anonymization by other means, then I suggest the
following replacement text.  This is blatantly stolen from the current
text about sampling:

  6.7.  Anonymization

     The metering process MAY be capable of anonymizing source and
     destination IP addresses in flow data before exporting them. It
     MAY support anonymization of port numbers and other
     fields. Please note that anonymization is not originally an
     application requirement, but derived from general requirements
     for treatment of measured traffic data within a network.

     If anonymization is supported, the anonymization configuration
     MUST be well defined. The anonymization configuration includes
     the anonymization method and all its parameters.

However, if we really think that the anonymization configuration must
be conveyed to the collector through the IPFIX protocol, I would
suggest the following wording (also stolen from the text on sampling,
but from the part on what happens when the sampling configuration
changes during operation):

  6.7.  Anonymization

     The metering process MAY be capable of anonymizing source and
     destination IP addresses in flow data before exporting them. It
     MAY support anonymization of port numbers and other
     fields. Please note that anonymization is not originally an
     application requirement, but derived from general requirements
     for treatment of measured traffic data within a network.

     If anonymization is supported, the anonymization configuration
     MUST be indicated to the collector. The anonymization
     configuration includes the anonymization method and all its
     parameters.
--
Simon.

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" 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 Jun 29 19:54:56 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11110
	for <ipfix-archive@lists.ietf.org>; Sun, 29 Jun 2003 19:54:56 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19WltI-0005Yi-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 29 Jun 2003 18:47:28 -0500
Received: from babar.switch.ch ([130.59.4.85])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19WltG-0005Yd-00
	for ipfix@net.doit.wisc.edu; Sun, 29 Jun 2003 18:47:26 -0500
Received: from babar (localhost [IPv6:::1])
	by babar.switch.ch (8.12.9+Sun/8.12.2) with ESMTP id h5TNlOEI001667;
	Mon, 30 Jun 2003 01:47:24 +0200 (CEST)
From: Simon Leinen <simon@limmat.switch.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16127.31372.561888.531729@limmat.switch.ch>
Date: Mon, 30 Jun 2003 01:47:24 +0200
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] draft-leinen-ipfix-eval-contrib-01.txt submitted
X-Mailer: VM 7.16 under Emacs 21.2.95.1
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

I submitted a revision of my protocol evaluation I-D.  For the
impatient, a copy can be found here for a couple of days:

http://www.switch.ch/misc/leinen/draft-leinen-ipfix-eval-contrib-01.txt

In order to get the evaluation process properly wrapped up and
documented, I'd suggest that this be adopted as a WG draft
(i.e. draft-ietf-ipfix-eval-00.txt) after the Vienna meeting, with the
intention of publishing it as an Informational RFC.
-- 
Simon.


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 30 15:55:31 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13890
	for <ipfix-archive@lists.ietf.org>; Mon, 30 Jun 2003 15:55:30 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19X4BI-0006RK-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 30 Jun 2003 14:19:16 -0500
Received: from palrel11.hp.com ([156.153.255.246])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19X4BH-0006RF-00
	for ipfix-reqs@net.doit.wisc.edu; Mon, 30 Jun 2003 14:19:15 -0500
Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62])
	by palrel11.hp.com (Postfix) with ESMTP
	id 643511C00CD7; Mon, 30 Jun 2003 12:19:12 -0700 (PDT)
Received: from xpabh2.ptp.hp.com (xpabh2.ptp.hp.com [15.1.28.61])
	by xparelay1.ptp.hp.com (Postfix) with ESMTP
	id C710510054D0; Mon, 30 Jun 2003 12:19:11 -0700 (PDT)
Received: by xpabh2.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <N9P6TT34>; Mon, 30 Jun 2003 12:19:11 -0700
Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50296011D@xsun01.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Tal Givoly'" <givoly@xacct.com>, Simon Leinen <simon@limmat.switch.ch>,
        ipfix-reqs@net.doit.wisc.edu
Subject: RE: [ipfix-reqs] Indicating Anonymization
Date: Mon, 30 Jun 2003 12:19:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Tal,

  I think your last statement sums it up:  "Is the anonymization requirement
well defined?"

  In general, if the requirement is to prevent data which is considered
private being used by anyone, then I think the policy would take place at
the IPFIX Observer level itself.  In this case any correlation is
meaningless, and runs counter to the expectation of privacty.

  One particular technique could be the use of a 32-bit random number
calculated by the observer each time it starts, and not available to an
external system.  This value could then simply be XOR'd with the actual IP
address.  This would provide a one way anonymization and guarantee that the
same IP address is always given the same id over the period the exporter is
up.

  I think one complicating factor is that you may want the IP address of
users anonymized, but NOT the IP address of servers on the Internet.  What
it means to configure anonymization behavior is probably an area of further
exploration.

  I'm unclear on why anonymizing ports is interesting.

  I'd prefer to see a separate Flow Attribute in the Information Model to
effectively inform any downstream consumer of the fact that what is being
delivered is NOT the IP address of the actual system, but some scrambled
value.  Semantically, this is a different piece of information, i.e. it is a
unique, but non-correlateable identifier.

Regards,

  Jeff Meyer

> -----Original Message-----
> From: Tal Givoly [mailto:givoly@xacct.com]
> Sent: Sunday, June 29, 2003 3:52 PM
> To: Simon Leinen; ipfix-reqs@net.doit.wisc.edu
> Subject: RE: [ipfix-reqs] Indicating Anonymization
> 
> 
> Simon,
> 
> It may be that that anonymization is perhaps even more 
> complex than this.
> 
> I assume that the original intent was that even without any form of
> encryption, the legitimate collector, or any party 
> eavesdropping on the
> communication, would not be able to correlate individual 
> user's usage back
> to that user. However, any form of anonymization that is a 
> 1-to-1 function
> of the original address space, and is completely specified, 
> implies that
> anybody could go back and discover the true identity of the 
> "anonymized"
> user. This would clearly be the case if one knows the 
> function applied to
> anonymize the address, and it is a 1-to-1 function (because you may be
> using, for instance, a 32-bit field to represent the "anonymized" IP
> address). One would know the function, if as you suggest, the function
> itself is completely specified.
> 
> Why should it be a 1-to-1 function, you may ask? Well, it is 
> important that
> the collector still be able to distinguish the identity of 
> the individual
> user sessions - although not necessarily the user itself. But 
> it shouldn't
> get mixed with other sessions.
> 
> Why should you use the same field type for the anonymized 
> values? Well,
> that's not mandatory - but it would make it possible for some 
> tools that are
> designed for operating on IP addresses, for instance, to operate on
> "anonymized" IP addresses. This is not mandatory, but may be useful.
> 
> Now, anonymization at the device level does introduce another 
> problem - any
> system downstream from the collector may not be able to 
> correlate back to
> individual user session. Supposing, for instance, IP addresses are
> dynamically assigned via DHCP or RADIUS (depending on access 
> technology) -
> then another source of information will actually have the 
> user's identity
> (be it MAC address for DHCP or user name/realm for RADIUS). 
> It will also be
> the source that allows for distinguishing two users sessions 
> sharing the
> same IP but at different times (from 9-10 user1 used IP1 
> while the same IP1
> was used between 10:05 and 11 by user2). So any anonymization 
> in the device
> would prevent downstream systems from recognizing that 
> different records
> represent different users traffic altogether.
> 
> This raises the questions:
> - Is anonymization requirement well-defined?
> - Is it even an important requirement for IPFIX?
> 
> I don't recall that there was much discussion ever about this 
> requirement.
> Wouldn't encryption of the links to avoid eavesdropping serve 
> most of the
> intended purpose? Why do we require the devices to support this?
> 
> Tal
> 
> -----Original Message-----
> From: majordomo listserver 
> [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Simon Leinen
> Sent: Sunday, June 29, 2003 1:40 PM
> To: ipfix-reqs@net.doit.wisc.edu
> Subject: [ipfix-reqs] Indicating Anonymization
> 
> 
> While updating my protocol evaluation I-D, I found the requirements
> I-D section on anonymization somewhat problematic.  I apologize
> bringing this up so late in the process.
> 
> The current revision (-10) has the following to say about
> anonymization:
> 
>   6.7.  Anonymization
> 
>      The exporting process MAY be capable of anonymizing source and
>      destination IP addresses in flow data before exporting them. It
>      MAY support anonymization of port numbers and other
>      fields. Please note that anonymization is not originally an
>      application requirement, but derived from general requirements
>      for treatment of measured traffic data within a network.
> 
>      When anonymized flow data is exported, this MUST be clearly
>      indicated to all receiving collecting processes, such that they
>      can distinguish anonymized data from non-anonymized data.
> 
> Note that there is no single generally accepted method for anonymizing
> flow export data (or even individual fields such as an IP address),
> and different situations may require different levels of
> anonymization.
> 
> Because of this, I think that it is not sufficient that the collector
> be able to "distinguish anonymized data from non-anonymized data", but
> it must also know the method and "degree" of anonymization.  This is
> similar to sampling, where it is not sufficient to know whether there
> is sampling going on or not, but one is also interested in sampling
> parameters such as sampling method (e.g. pseudo-random,
> packet/byte/time/flow-based) and parameters (e.g. sampling interval).
> 
> On the other hand, whether and how anonymization is performed will be
> purely a matter of configuration of the exporting device, and will not
> change during normal operation.  This is in contrast to sampling,
> where the parameters may change to adapt to the offered load.  So one
> could argue that it's not even necessary to report anonymization,
> because of the general assumption that the collector can know the
> static configuration of the exporting device by some other means.
> 
> If we agree that collectors can obtain the necessary knowledge about
> the configuration of anonymization by other means, then I suggest the
> following replacement text.  This is blatantly stolen from the current
> text about sampling:
> 
>   6.7.  Anonymization
> 
>      The metering process MAY be capable of anonymizing source and
>      destination IP addresses in flow data before exporting them. It
>      MAY support anonymization of port numbers and other
>      fields. Please note that anonymization is not originally an
>      application requirement, but derived from general requirements
>      for treatment of measured traffic data within a network.
> 
>      If anonymization is supported, the anonymization configuration
>      MUST be well defined. The anonymization configuration includes
>      the anonymization method and all its parameters.
> 
> However, if we really think that the anonymization configuration must
> be conveyed to the collector through the IPFIX protocol, I would
> suggest the following wording (also stolen from the text on sampling,
> but from the part on what happens when the sampling configuration
> changes during operation):
> 
>   6.7.  Anonymization
> 
>      The metering process MAY be capable of anonymizing source and
>      destination IP addresses in flow data before exporting them. It
>      MAY support anonymization of port numbers and other
>      fields. Please note that anonymization is not originally an
>      application requirement, but derived from general requirements
>      for treatment of measured traffic data within a network.
> 
>      If anonymization is supported, the anonymization configuration
>      MUST be indicated to the collector. The anonymization
>      configuration includes the anonymization method and all its
>      parameters.
> --
> Simon.
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
> 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 Jun 30 18:27:04 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19707
	for <ipfix-archive@lists.ietf.org>; Mon, 30 Jun 2003 18:27:02 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19X6sh-0003Km-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 30 Jun 2003 17:12:15 -0500
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19X6sf-0003KR-00
	for ipfix-reqs@net.doit.wisc.edu; Mon, 30 Jun 2003 17:12:13 -0500
Received: from Givoly ([192.168.0.3])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h5UMJgL24159;
	Mon, 30 Jun 2003 15:19:42 -0700
From: "Tal Givoly" <givoly@xacct.com>
To: "MEYER,JEFFREY D \(HP-Cupertino,ex1\)" <jeff.meyer2@hp.com>,
        "Simon Leinen" <simon@limmat.switch.ch>,
        <ipfix-reqs@net.doit.wisc.edu>
Subject: RE: [ipfix-reqs] Indicating Anonymization
Date: Mon, 30 Jun 2003 15:12:04 -0700
Message-ID: <DLEIIIOHMNPJPNMKGEFDKEECDLAA.givoly@xacct.com>
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.2910.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A50296011D@xsun01.ptp.hp.com>
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Jeff,

That, indeed, was the main point I was trying to make.

I'll explain why it seems that the anonymization algorithm you suggest is
too simple - if someone can come up with an effective alternative, the
requirement may have some more merit than it has now.

Why is XOR with a random number too simple a function if one wants to
anonymize traffic?

If the same 32-bit field is XORed for all instances of the same IP address,
then it would be very simple to identify that pattern. For instance, traffic
flowing to or from port 53 would be DNS traffic. It would be very easy to
figure out which are these DNS servers, as there aren't that many associated
with an organization. Same thing for SMTP/POP3 servers and any other server
with well-known ports. So, basically, it wouldn't be difficult to identify
the constant with which all IP addresses are XORed.

This may have lead people to think about anonymization of other fields, such
as port numbers... I believe that that too is a futile effort if it is just
a fixed XOR pattern. Not many protocols have the same source/destination
port - the ones that do stand out in the crowd. DNS is one of them. Most DNS
traffic between servers shares port 53 for both client and server. So once
you identify the few protocols that identify this pattern and solve a few
simple equations, you know the mask that was applied.

Getting back to the bigger picture - can anybody whom contributed to the
original requirements provide some rationale and perhaps even propose at
least one transformation function that servers the purpose?

Tal

-----Original Message-----
From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com]
Sent: Monday, June 30, 2003 12:19 PM
To: 'Tal Givoly'; Simon Leinen; ipfix-reqs@net.doit.wisc.edu
Subject: RE: [ipfix-reqs] Indicating Anonymization


Tal,

  I think your last statement sums it up:  "Is the anonymization requirement
well defined?"

  In general, if the requirement is to prevent data which is considered
private being used by anyone, then I think the policy would take place at
the IPFIX Observer level itself.  In this case any correlation is
meaningless, and runs counter to the expectation of privacty.

  One particular technique could be the use of a 32-bit random number
calculated by the observer each time it starts, and not available to an
external system.  This value could then simply be XOR'd with the actual IP
address.  This would provide a one way anonymization and guarantee that the
same IP address is always given the same id over the period the exporter is
up.

  I think one complicating factor is that you may want the IP address of
users anonymized, but NOT the IP address of servers on the Internet.  What
it means to configure anonymization behavior is probably an area of further
exploration.

  I'm unclear on why anonymizing ports is interesting.

  I'd prefer to see a separate Flow Attribute in the Information Model to
effectively inform any downstream consumer of the fact that what is being
delivered is NOT the IP address of the actual system, but some scrambled
value.  Semantically, this is a different piece of information, i.e. it is a
unique, but non-correlateable identifier.

Regards,

  Jeff Meyer

> -----Original Message-----
> From: Tal Givoly [mailto:givoly@xacct.com]
> Sent: Sunday, June 29, 2003 3:52 PM
> To: Simon Leinen; ipfix-reqs@net.doit.wisc.edu
> Subject: RE: [ipfix-reqs] Indicating Anonymization
>
>
> Simon,
>
> It may be that that anonymization is perhaps even more
> complex than this.
>
> I assume that the original intent was that even without any form of
> encryption, the legitimate collector, or any party
> eavesdropping on the
> communication, would not be able to correlate individual
> user's usage back
> to that user. However, any form of anonymization that is a
> 1-to-1 function
> of the original address space, and is completely specified,
> implies that
> anybody could go back and discover the true identity of the
> "anonymized"
> user. This would clearly be the case if one knows the
> function applied to
> anonymize the address, and it is a 1-to-1 function (because you may be
> using, for instance, a 32-bit field to represent the "anonymized" IP
> address). One would know the function, if as you suggest, the function
> itself is completely specified.
>
> Why should it be a 1-to-1 function, you may ask? Well, it is
> important that
> the collector still be able to distinguish the identity of
> the individual
> user sessions - although not necessarily the user itself. But
> it shouldn't
> get mixed with other sessions.
>
> Why should you use the same field type for the anonymized
> values? Well,
> that's not mandatory - but it would make it possible for some
> tools that are
> designed for operating on IP addresses, for instance, to operate on
> "anonymized" IP addresses. This is not mandatory, but may be useful.
>
> Now, anonymization at the device level does introduce another
> problem - any
> system downstream from the collector may not be able to
> correlate back to
> individual user session. Supposing, for instance, IP addresses are
> dynamically assigned via DHCP or RADIUS (depending on access
> technology) -
> then another source of information will actually have the
> user's identity
> (be it MAC address for DHCP or user name/realm for RADIUS).
> It will also be
> the source that allows for distinguishing two users sessions
> sharing the
> same IP but at different times (from 9-10 user1 used IP1
> while the same IP1
> was used between 10:05 and 11 by user2). So any anonymization
> in the device
> would prevent downstream systems from recognizing that
> different records
> represent different users traffic altogether.
>
> This raises the questions:
> - Is anonymization requirement well-defined?
> - Is it even an important requirement for IPFIX?
>
> I don't recall that there was much discussion ever about this
> requirement.
> Wouldn't encryption of the links to avoid eavesdropping serve
> most of the
> intended purpose? Why do we require the devices to support this?
>
> Tal
>
> -----Original Message-----
> From: majordomo listserver
> [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Simon Leinen
> Sent: Sunday, June 29, 2003 1:40 PM
> To: ipfix-reqs@net.doit.wisc.edu
> Subject: [ipfix-reqs] Indicating Anonymization
>
>
> While updating my protocol evaluation I-D, I found the requirements
> I-D section on anonymization somewhat problematic.  I apologize
> bringing this up so late in the process.
>
> The current revision (-10) has the following to say about
> anonymization:
>
>   6.7.  Anonymization
>
>      The exporting process MAY be capable of anonymizing source and
>      destination IP addresses in flow data before exporting them. It
>      MAY support anonymization of port numbers and other
>      fields. Please note that anonymization is not originally an
>      application requirement, but derived from general requirements
>      for treatment of measured traffic data within a network.
>
>      When anonymized flow data is exported, this MUST be clearly
>      indicated to all receiving collecting processes, such that they
>      can distinguish anonymized data from non-anonymized data.
>
> Note that there is no single generally accepted method for anonymizing
> flow export data (or even individual fields such as an IP address),
> and different situations may require different levels of
> anonymization.
>
> Because of this, I think that it is not sufficient that the collector
> be able to "distinguish anonymized data from non-anonymized data", but
> it must also know the method and "degree" of anonymization.  This is
> similar to sampling, where it is not sufficient to know whether there
> is sampling going on or not, but one is also interested in sampling
> parameters such as sampling method (e.g. pseudo-random,
> packet/byte/time/flow-based) and parameters (e.g. sampling interval).
>
> On the other hand, whether and how anonymization is performed will be
> purely a matter of configuration of the exporting device, and will not
> change during normal operation.  This is in contrast to sampling,
> where the parameters may change to adapt to the offered load.  So one
> could argue that it's not even necessary to report anonymization,
> because of the general assumption that the collector can know the
> static configuration of the exporting device by some other means.
>
> If we agree that collectors can obtain the necessary knowledge about
> the configuration of anonymization by other means, then I suggest the
> following replacement text.  This is blatantly stolen from the current
> text about sampling:
>
>   6.7.  Anonymization
>
>      The metering process MAY be capable of anonymizing source and
>      destination IP addresses in flow data before exporting them. It
>      MAY support anonymization of port numbers and other
>      fields. Please note that anonymization is not originally an
>      application requirement, but derived from general requirements
>      for treatment of measured traffic data within a network.
>
>      If anonymization is supported, the anonymization configuration
>      MUST be well defined. The anonymization configuration includes
>      the anonymization method and all its parameters.
>
> However, if we really think that the anonymization configuration must
> be conveyed to the collector through the IPFIX protocol, I would
> suggest the following wording (also stolen from the text on sampling,
> but from the part on what happens when the sampling configuration
> changes during operation):
>
>   6.7.  Anonymization
>
>      The metering process MAY be capable of anonymizing source and
>      destination IP addresses in flow data before exporting them. It
>      MAY support anonymization of port numbers and other
>      fields. Please note that anonymization is not originally an
>      application requirement, but derived from general requirements
>      for treatment of measured traffic data within a network.
>
>      If anonymization is supported, the anonymization configuration
>      MUST be indicated to the collector. The anonymization
>      configuration includes the anonymization method and all its
>      parameters.
> --
> Simon.
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help"
> 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 Jun 30 20:31:54 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23840
	for <ipfix-archive@lists.ietf.org>; Mon, 30 Jun 2003 20:31:54 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19X8uM-0006SC-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 30 Jun 2003 19:22:06 -0500
Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19X8uL-0006S6-00
	for ipfix@net.doit.wisc.edu; Mon, 30 Jun 2003 19:22:05 -0500
Date: Mon, 30 Jun 2003 19:22:05 -0500
From: Dave Plonka <plonka@doit.wisc.edu>
To: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] draft-leinen-ipfix-eval-contrib-01.txt submitted
Message-ID: <20030630192205.A24266@doit.wisc.edu>
Reply-To: plonka@doit.wisc.edu
References: <16127.31372.561888.531729@limmat.switch.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <16127.31372.561888.531729@limmat.switch.ch>; from simon@limmat.switch.ch on Mon, Jun 30, 2003 at 01:47:24AM +0200
X-Organization: University of Wisconsin-Madison, DoIT Network Services
X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL)
X-URL: http://net.doit.wisc.edu/~plonka/
X-VMS-Error: %SYSTEM-E-NOTORIGIN, the origin transaction branch is not in this process
X-Shakespearean-Insult: Thou dissembling weather-bitten bladder
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

On Mon, Jun 30, 2003 at 01:47:24AM +0200, Simon Leinen wrote:
> I submitted a revision of my protocol evaluation I-D.  For the
> impatient, a copy can be found here for a couple of days:
> 
> http://www.switch.ch/misc/leinen/draft-leinen-ipfix-eval-contrib-01.txt

I've also mirrored it on the IPFIX site:

   http://ipfix.doit.wisc.edu/eval/draft-leinen-ipfix-eval-contrib-01.txt

So I think the IPFIX site is up to date on mirroring all the current drafts.
Let me know if I'm wrong.  (I've tried to improve the main index page so
that its easy to find the mirror sub-dirs, /reqs/, /eval/, etc.)

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  Mon Jun 30 22:13:31 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26622
	for <ipfix-archive@lists.ietf.org>; Mon, 30 Jun 2003 22:13:31 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19XATH-0001In-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 30 Jun 2003 21:02:15 -0500
Received: from mailhost2.auckland.ac.nz ([130.216.1.4])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19XATG-0001Ig-00
	for ipfix@net.doit.wisc.edu; Mon, 30 Jun 2003 21:02:14 -0500
Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61])
	by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h6122C8W002479
	for <ipfix@net.doit.wisc.edu>; Tue, 1 Jul 2003 14:02:12 +1200 (NZST)
Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123])
	by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.5-GR)
	with ESMTP id ARQ42196;
	Tue, 1 Jul 2003 14:02:10 +1200 (NZST)
Received: (from apache@localhost)
	by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h6122AA06615
	for ipfix@net.doit.wisc.edu; Tue, 1 Jul 2003 14:02:10 +1200
X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f
Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz
	[130.216.4.167]) by hotlava.auckland.ac.nz (Horde) with HTTP for
	<jbro111@hotlava.auckland.ac.nz>; Tue,  1 Jul 2003 14:02:10 +1200
Message-ID: <1057024930.1a18740ffc086@hotlava.auckland.ac.nz>
Date: Tue,  1 Jul 2003 14:02:10 +1200
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] IPFIX Agenda for Vienna IETF meeting
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP:  130.216.4.167
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


Hello all:

Here's the latest draft of our agenda for the Vienna meeting.
For those who can't get to Vienna, Marshall Rose says he's looking
into providing text conferencing (jabber); that worked well for
IPFIX at the Atlanta meeting last November.

Cheers, Nevil


IPFIX Agenda for IETF 57, Vienna
--------------------------------

The IPFIX WG meeting is scheduled for Wednesday 16 Jul 03,
at 1530 (last session Wednesday afternoon).

time        Item
(minutes)

 5  1) Agenda Review

    2) Requirements draft, Juergen Quittek
       (status as at 20 Jun 03: being revised to address IESG comments)
10       draft-ietf-ipfix-reqs-10.txt

    3) Evaluation Report draft, Simon Leinen
10       draft-leinen-ipfix-eval-contrib-01.txt 
       Proposed that this be adopted as a WG draft (i.e.
       draft-ietf-ipfix-eval-00.txt) after the Vienna meeting,
       to be submitted to IESG as an Informational RFC.

    4) New drafts - brief overview presentation for each, 
       discussion of as-yet-unwritten sections and unresolved issues.
       The drafts are
15      * draft-ietf-ipfix-arch-00.txt
15      * draft-ietf-ipfix-info-00.txt
15      * draft-ietf-ipfix-protocol-00.txt
15        * draft-ietf-ipfix-as-00.txt

    5) Short Presentations
10      * nFlow, Luca Deri (offered, to be confirmed)
10      * Per-packet record proposal (pktId), Changhoon Kim
            draft-kim-ipfix-ppr-00.txt
  
 5  6) Review of WG Milestones

 5  7) Anything else

If you have other items you'd like to see discussed, please advise
the WG chairs, by email to ipfix-chairs@net.doit.wisc.edu

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@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 Jun 30 22:41:50 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27310
	for <ipfix-archive@lists.ietf.org>; Mon, 30 Jun 2003 22:41:49 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19XAvO-00027v-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 30 Jun 2003 21:31:18 -0500
Received: from atlrel6.hp.com ([156.153.255.205])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19XAvM-00027q-00
	for ipfix-reqs@net.doit.wisc.edu; Mon, 30 Jun 2003 21:31:16 -0500
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel6.hp.com (Postfix) with ESMTP
	id 368761C018C9; Mon, 30 Jun 2003 22:31:16 -0400 (EDT)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP
	id E1F711C00A5F; Mon, 30 Jun 2003 22:31:12 -0400 (EDT)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <NRY64M0T>; Mon, 30 Jun 2003 22:31:12 -0400
Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960122@xsun01.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Tal Givoly'" <givoly@xacct.com>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        Simon Leinen <simon@limmat.switch.ch>, ipfix-reqs@net.doit.wisc.edu
Subject: RE: [ipfix-reqs] Indicating Anonymization
Date: Mon, 30 Jun 2003 22:31:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Tal,

  Reversability of the XOR pattern if you have a known address which can
be identified by its flow behavior does sound like a pretty simple attack.

  I won't defend it, but would be curious in effective alternatives.  I'm
not a cryptographer...

  Assuming such a mechanism is defined, I'd still suggest it be carried as
a unique flow attribute, and I believe that providing for anonymizing only
a user addresses and not server addresses would prove more useful.


  Alternatively, data can effectively be anonymized once aggregated
at the collector.

  In other words, reports saying that some number of unique addresses
showed some behavior or had some quality in common provides information
of interest, but does not divulge individual identities.

  Perhaps this is a more reasonable approach...

-- Jeff

> -----Original Message-----
> From: Tal Givoly [mailto:givoly@xacct.com]
> Sent: Monday, June 30, 2003 3:12 PM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1); Simon Leinen;
> ipfix-reqs@net.doit.wisc.edu
> Subject: RE: [ipfix-reqs] Indicating Anonymization
> 
> 
> Jeff,
> 
> That, indeed, was the main point I was trying to make.
> 
> I'll explain why it seems that the anonymization algorithm 
> you suggest is
> too simple - if someone can come up with an effective alternative, the
> requirement may have some more merit than it has now.
> 
> Why is XOR with a random number too simple a function if one wants to
> anonymize traffic?
> 
> If the same 32-bit field is XORed for all instances of the 
> same IP address,
> then it would be very simple to identify that pattern. For 
> instance, traffic
> flowing to or from port 53 would be DNS traffic. It would be 
> very easy to
> figure out which are these DNS servers, as there aren't that 
> many associated
> with an organization. Same thing for SMTP/POP3 servers and 
> any other server
> with well-known ports. So, basically, it wouldn't be 
> difficult to identify
> the constant with which all IP addresses are XORed.
> 
> This may have lead people to think about anonymization of 
> other fields, such
> as port numbers... I believe that that too is a futile effort 
> if it is just
> a fixed XOR pattern. Not many protocols have the same 
> source/destination
> port - the ones that do stand out in the crowd. DNS is one of 
> them. Most DNS
> traffic between servers shares port 53 for both client and 
> server. So once
> you identify the few protocols that identify this pattern and 
> solve a few
> simple equations, you know the mask that was applied.
> 
> Getting back to the bigger picture - can anybody whom 
> contributed to the
> original requirements provide some rationale and perhaps even 
> propose at
> least one transformation function that servers the purpose?
> 
> Tal
> 
> -----Original Message-----
> From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com]
> Sent: Monday, June 30, 2003 12:19 PM
> To: 'Tal Givoly'; Simon Leinen; ipfix-reqs@net.doit.wisc.edu
> Subject: RE: [ipfix-reqs] Indicating Anonymization
> 
> 
> Tal,
> 
>   I think your last statement sums it up:  "Is the 
> anonymization requirement
> well defined?"
> 
>   In general, if the requirement is to prevent data which is 
> considered
> private being used by anyone, then I think the policy would 
> take place at
> the IPFIX Observer level itself.  In this case any correlation is
> meaningless, and runs counter to the expectation of privacty.
> 
>   One particular technique could be the use of a 32-bit random number
> calculated by the observer each time it starts, and not 
> available to an
> external system.  This value could then simply be XOR'd with 
> the actual IP
> address.  This would provide a one way anonymization and 
> guarantee that the
> same IP address is always given the same id over the period 
> the exporter is
> up.
> 
>   I think one complicating factor is that you may want the IP 
> address of
> users anonymized, but NOT the IP address of servers on the 
> Internet.  What
> it means to configure anonymization behavior is probably an 
> area of further
> exploration.
> 
>   I'm unclear on why anonymizing ports is interesting.
> 
>   I'd prefer to see a separate Flow Attribute in the 
> Information Model to
> effectively inform any downstream consumer of the fact that 
> what is being
> delivered is NOT the IP address of the actual system, but 
> some scrambled
> value.  Semantically, this is a different piece of 
> information, i.e. it is a
> unique, but non-correlateable identifier.
> 
> Regards,
> 
>   Jeff Meyer
> 
> > -----Original Message-----
> > From: Tal Givoly [mailto:givoly@xacct.com]
> > Sent: Sunday, June 29, 2003 3:52 PM
> > To: Simon Leinen; ipfix-reqs@net.doit.wisc.edu
> > Subject: RE: [ipfix-reqs] Indicating Anonymization
> >
> >
> > Simon,
> >
> > It may be that that anonymization is perhaps even more
> > complex than this.
> >
> > I assume that the original intent was that even without any form of
> > encryption, the legitimate collector, or any party
> > eavesdropping on the
> > communication, would not be able to correlate individual
> > user's usage back
> > to that user. However, any form of anonymization that is a
> > 1-to-1 function
> > of the original address space, and is completely specified,
> > implies that
> > anybody could go back and discover the true identity of the
> > "anonymized"
> > user. This would clearly be the case if one knows the
> > function applied to
> > anonymize the address, and it is a 1-to-1 function (because 
> you may be
> > using, for instance, a 32-bit field to represent the "anonymized" IP
> > address). One would know the function, if as you suggest, 
> the function
> > itself is completely specified.
> >
> > Why should it be a 1-to-1 function, you may ask? Well, it is
> > important that
> > the collector still be able to distinguish the identity of
> > the individual
> > user sessions - although not necessarily the user itself. But
> > it shouldn't
> > get mixed with other sessions.
> >
> > Why should you use the same field type for the anonymized
> > values? Well,
> > that's not mandatory - but it would make it possible for some
> > tools that are
> > designed for operating on IP addresses, for instance, to operate on
> > "anonymized" IP addresses. This is not mandatory, but may be useful.
> >
> > Now, anonymization at the device level does introduce another
> > problem - any
> > system downstream from the collector may not be able to
> > correlate back to
> > individual user session. Supposing, for instance, IP addresses are
> > dynamically assigned via DHCP or RADIUS (depending on access
> > technology) -
> > then another source of information will actually have the
> > user's identity
> > (be it MAC address for DHCP or user name/realm for RADIUS).
> > It will also be
> > the source that allows for distinguishing two users sessions
> > sharing the
> > same IP but at different times (from 9-10 user1 used IP1
> > while the same IP1
> > was used between 10:05 and 11 by user2). So any anonymization
> > in the device
> > would prevent downstream systems from recognizing that
> > different records
> > represent different users traffic altogether.
> >
> > This raises the questions:
> > - Is anonymization requirement well-defined?
> > - Is it even an important requirement for IPFIX?
> >
> > I don't recall that there was much discussion ever about this
> > requirement.
> > Wouldn't encryption of the links to avoid eavesdropping serve
> > most of the
> > intended purpose? Why do we require the devices to support this?
> >
> > Tal
> >
> > -----Original Message-----
> > From: majordomo listserver
> > [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> > Of Simon Leinen
> > Sent: Sunday, June 29, 2003 1:40 PM
> > To: ipfix-reqs@net.doit.wisc.edu
> > Subject: [ipfix-reqs] Indicating Anonymization
> >
> >
> > While updating my protocol evaluation I-D, I found the requirements
> > I-D section on anonymization somewhat problematic.  I apologize
> > bringing this up so late in the process.
> >
> > The current revision (-10) has the following to say about
> > anonymization:
> >
> >   6.7.  Anonymization
> >
> >      The exporting process MAY be capable of anonymizing source and
> >      destination IP addresses in flow data before exporting them. It
> >      MAY support anonymization of port numbers and other
> >      fields. Please note that anonymization is not originally an
> >      application requirement, but derived from general requirements
> >      for treatment of measured traffic data within a network.
> >
> >      When anonymized flow data is exported, this MUST be clearly
> >      indicated to all receiving collecting processes, such that they
> >      can distinguish anonymized data from non-anonymized data.
> >
> > Note that there is no single generally accepted method for 
> anonymizing
> > flow export data (or even individual fields such as an IP address),
> > and different situations may require different levels of
> > anonymization.
> >
> > Because of this, I think that it is not sufficient that the 
> collector
> > be able to "distinguish anonymized data from non-anonymized 
> data", but
> > it must also know the method and "degree" of anonymization.  This is
> > similar to sampling, where it is not sufficient to know 
> whether there
> > is sampling going on or not, but one is also interested in sampling
> > parameters such as sampling method (e.g. pseudo-random,
> > packet/byte/time/flow-based) and parameters (e.g. sampling 
> interval).
> >
> > On the other hand, whether and how anonymization is 
> performed will be
> > purely a matter of configuration of the exporting device, 
> and will not
> > change during normal operation.  This is in contrast to sampling,
> > where the parameters may change to adapt to the offered 
> load.  So one
> > could argue that it's not even necessary to report anonymization,
> > because of the general assumption that the collector can know the
> > static configuration of the exporting device by some other means.
> >
> > If we agree that collectors can obtain the necessary knowledge about
> > the configuration of anonymization by other means, then I 
> suggest the
> > following replacement text.  This is blatantly stolen from 
> the current
> > text about sampling:
> >
> >   6.7.  Anonymization
> >
> >      The metering process MAY be capable of anonymizing source and
> >      destination IP addresses in flow data before exporting them. It
> >      MAY support anonymization of port numbers and other
> >      fields. Please note that anonymization is not originally an
> >      application requirement, but derived from general requirements
> >      for treatment of measured traffic data within a network.
> >
> >      If anonymization is supported, the anonymization configuration
> >      MUST be well defined. The anonymization configuration includes
> >      the anonymization method and all its parameters.
> >
> > However, if we really think that the anonymization 
> configuration must
> > be conveyed to the collector through the IPFIX protocol, I would
> > suggest the following wording (also stolen from the text on 
> sampling,
> > but from the part on what happens when the sampling configuration
> > changes during operation):
> >
> >   6.7.  Anonymization
> >
> >      The metering process MAY be capable of anonymizing source and
> >      destination IP addresses in flow data before exporting them. It
> >      MAY support anonymization of port numbers and other
> >      fields. Please note that anonymization is not originally an
> >      application requirement, but derived from general requirements
> >      for treatment of measured traffic data within a network.
> >
> >      If anonymization is supported, the anonymization configuration
> >      MUST be indicated to the collector. The anonymization
> >      configuration includes the anonymization method and all its
> >      parameters.
> > --
> > Simon.
> >
> > --
> > Help        mailto:majordomo@net.doit.wisc.edu and say "help"
> > 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/