Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03

From: Atsushi Kobayashi <[email-masked]>
Date: Wed, 10 Jun 2009 21:39:41 +0900

Dear Gerhard, and co-authors,

Sorry for late reply. I really appreciate your detailed review.
I put my thought for your comments.

On Tue, 26 May 2009 14:48:14 +0200
Gerhard Muenz <[email-masked]> wrote:

> 
> Dear Atsushi, all,
> 
> Find below my comments for draft-ietf-ipfix-mediators-problem-statement-03
> 
> I think the purpose of the document is much clearer now.
> 
> Apart from the terminology and the introduction, which should be
> rewritten, the document is in a good shape.
> 
> In my opinion, the terminology related to Mediation must be rethought
> another time before publishing this problem statement as an RFC.
> The current terminology section defines the following terms:
> 
> *IPFIX Mediation*
> = a function
> 
> *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor*
> = specific types of IPFIX Mediation
> 
Do you suggest that they are a specific type of device?

e.g.

   IPFIX Proxy

      An IPFIX Proxy is a type of IPFIX Mediator that relays incoming
                                        ^^^^^^^^ 
      Transport Sessions to one or multiple Collectors. 

Your points are reasonable for me, the further discussion with co-authors
is needed to address it.

> *IPFIX Mediator*
> = devices that implements IPFIX Mediation
> 

If "IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor" are
defined as the devices, I think that the following issues can be solved. 

> This terminology has several flaws:
> - On the one hand, you have troubles to distinguish between IPFIX
> Mediation implemented at an "Original Exporter" and IPFIX Mediation
> implemented at a "separate IPFIX Mediator/Concentrator/...".
> - On the other hand, the terms do not fit into the current terminology
> scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we
> talk about the instantiation of a specific function.

I will add "XXX Process" terms in framework draft rather than problem
statement. It seems better that the problem statement draft does not
include the "XXX Process" terms illustrating the implementation.

> - Finally, the definition of IPFIX Concentrator does not correspond to
> the usage of this term in RFC3917. There, a Concentrator is a device,
> not a function.
> 
> I like the approach that has been chosen by PSAMP. There, we distinguish
> between "Selectors" (which are abstract selection functions) and
> "Selection Processes" (which are instantiations of Selectors). Selection
> Processes are finally part of Devices (i.e., PSAMP Exporters). I suggest
> to apply this approach to Mediation as well.
> 
> In the case of Mediation, we would have abstract Mediation Functions
> (anonymization, aggregation, sampling, proxy, distribution). These would
> be instantiated in a Mediation Process. A Mediation Process can then be
> part of an Exporter (Original Exporter), Collector, or Mediator.

Yes. We can describe the your suggestion as "Intermediate Process" in
framework draft. 

> Regards,
> Gerhard
> 
> > Abstract
> > 
> >    Flow-based measurement is a popular method for various network
> >    monitoring usages.  The sharing of flow-based information for
> >    monitoring applications having different requirements raises some
> >    open issues in terms of measurement system scalability, flow-based
> >    measurement flexibility, and export reliability that IPFIX Mediation
> >    may help resolve.  IPFIX Mediation covers two classes of mediation:
> >    context mediation for traffic data and transport mediation for
> 
> content mediation
> 
> >    transport protocols.  This document describes the IPFIX Mediation
> >    applicability examples, along with some problems that network
> >    administrators have been facing.
> 
> > 1.  Introduction
> > 
> >    While the IPFIX requirements defined in [RFC3917] mention an
> >    intermediate function, such as an IPFIX Proxy or an IPFIX
> >    Concentrator, there are no documents defining the function called
> >    IPFIX Mediation.  IPFIX Mediation is a generic function that covers
> >    the manipulation of IPFIX Flow Records, PSAMP Packet Reports, entire
> >    IPFIX Messages, or their transmission.  This document describes
> >    general problems, applicability examples, and defines the terminology
> >    (IPFIX Proxy, Concentrator, etc.) for referring to different use
> >    cases for IPFIX Mediation.  Furthermore, some specific problems
> >    related to the IPFIX protocol [RFC5101] when applying IPFIX Mediation
> >    are addressed.
> 
> The only motivation for IPFIX Mediation given in this introduction is
> that the term has not yet defined in any document. This cannot be a
> reason for publishing an RFC ;)

Yes, indeed.
> 
> I would like to see a much stronger motivation elaborating the arguments
> and problems of the abstract.
> 

I will improve it.

> >    This document is structured as follows: section 2 describes the
> >    terminology used in this document, section 3 gives an IPFIX/PSAMP
> >    document overview, section 4 introduces general problems related to
> >    flow-based measurement, section 5 describes some applicability
> >    examples where IPFIX Mediations would be beneficial, and, finally,
> >    section 6 describes some problems an IPFIX Mediation implementation
> >    might face.
> 
> 
> > 2.  Terminology and Definition
> 
> Definitions
> 
> >    The terms in this section are in line with those in the IPFIX
> >    Protocol specifications [RFC5101] and the PSAMP specification
> >    document [RFC5476].  The terms Observation Point, Observation Domain,
> >    Flow Key, Flow Record, Data Record, Exporting Process, Exporter,
> >    IPFIX Device, Collecting Process, Collector, IPFIX Message, Metering
> >    Process, Transport Session, Information Element, and Template
> >    Withdrawal Message, are defined in the IPFIX protocol specifications
> >    [RFC5101].  The terms Packet Report, Sampling, Filtering, PSAMP
> >    Device, and Configured Selection Fraction are defined in the PSAMP
> >    specification document [RFC5476].  Furthermore, new terminology to be
> >    used in the context of IPFIX Mediation is defined in this section.
> >    All these terms have an initial capital letter in this document.
> >
> >    While IPFIX Mediation can process both Flow Records and Packet
> >    Reports, this document prefers the more generic "Data Record" term as
> >    this is a more generic term, unless the reference to the IPFIX Flow
> >    Record or PSAMP Packet Report is required.
> >    this is a more generic term, unless the reference to the IPFIX Flow
> >    Record or PSAMP Packet Report is required.
> 
> better:
> "IPFIX Mediation can process IPFIX Flow Records, PSAMP Packet Reports,
> and Data Records defined by Options Templates. In this document, we use
> the generic term "Data Record" for all of these unless an explicit
> distinction is required."
> 
Thanks.

> >    IPFIX Mediation
> > 
> >       IPFIX Mediation is a generic function that covers the manipulation
> 
> remove "generic" ?
> 
> >       of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX
> >       Messages, or their transmission.  The IPFIX Mediation offers one
> 
> Could be read as "covers the transmission of...", which would make an
> Exporting Process a Mediation function.
>
> Also, you sentence does not include "Options Data Records" (I put this
> in quotes because it is not an official term).

Yes, indeed.
> 
> maybe:
> "...covers the manipulation of the content and transmission of Data
> Records and IPFIX Messages."

Fine.
> 
> >       or multiple of the following capabilities:
> > 
> >       *  content mediation that changes Flow Records/Packet Reports
> >          information
> > 
> >          +  aggregating Flow Records/Packet Reports based on a new set
> >             of Flow Key fields
> > 
> >          +  correlating a set of Flow Records/Packet Reports
> > 
> >          +  filtering and selecting Flow Records/Packet Reports
> > 
> >          +  modifying Flow Records/Packet Reports, including:
> > 
> >             -  changing the value of specified Information Elements
> > 
> >             -  adding new Information Elements by deriving further Flow
> >                or packet properties from existing fields (for example:
> >                calculating new metrics or new counters)
> > 
> >             -  deleting specified Information Elements
> 
> in the whole definition:
> s/Flow Records\/Packet Reports/Data Records
> 
> >       *  transport mediation
> > 
> >          +  changing the transport protocol that carries IPFIX Messages
> > 
> >          +  rerouting entire IPFIX Messages to an appropriate Collecting
> >             Process
> 
> rerouting => relaying ?
> 
Yes.

> >          +  replicating Flow Records/Packet Reports (or the entire IPFIX
> >             Messages)
> 
> s/Flow Records\/Packet Reports/Data Records
> 
> >    IPFIX Mediator
> > 
> >       An IPFIX Mediator is an IPFIX Device that implements one or more
> >       IPFIX Mediation capabilities.  Examples are devices such as
> >       routers, switches, network management systems (NMS), etc.
> > 
> >    Original Exporter
> > 
> >       An Original Exporter is an IPFIX Device that hosts the Observation
> >       Points where the metered IP packets are observed.
> > 
> >    IPFIX Proxy
> > 
> >       An IPFIX Proxy is a type of IPFIX Mediation that relays incoming
> 
> remove "An"
> 
> >       Transport Sessions to one or multiple Collectors.  The protocols
> >       used at the input and the output can be different, which implies
> >       that IPFIX Messages, Data Records, and Template Records need to be
> >       encoded, e.g., for converting from a legacy protocol to IPFIX.  An
> >       IPFIX Proxy is not implemented on the Original Exporter, but as a
> >       separate Mediator.
> 
> I would remove the last sentence. Otherwise, you need to explain what
> you mean by "separate Mediator".
> 
> >    IPFIX Concentrator
> > 
> >       An IPFIX Concentrator is a type of IPFIX Mediation that receives
> >       Flow Records/Packet Reports, correlates them, aggregates them, or
> 
> s/Flow Records\/Packet Reports/Data Records
> 
> >       modifies them, then exports the new Data Records.
> > 
> >    IPFIX Distributor
> > 
> >       An IPFIX Distributor is a type of IPFIX Mediation that distributes
> >       Data Records to one or multiple IPFIX Collectors.  The decision as
> >       to which IPFIX Collector a Data Record is exported can be
> >       determined by filtering certain field values or other properties
> >       derived from the Data Record.
> > 
> >    IPFIX Masquerading Proxy
> > 
> >       An IPFIX Masquerading Proxy is a type of IPFIX Mediation that
> >       screens out parts of input Flow Records/Packet Reports according
> 
> s/Flow Records\/Packet Reports/Data Records
> 
> >       to configured policies.  It can thus, for example, hide the
> >       network topology information or customers' IP addresses.
> 
> 
> > 3.  IPFIX/PSAMP Documents Overview
> > 
> > 3.1.  IPFIX Documents Overview
> > 
> >    The IPFIX protocol [RFC5101] provides network administrators with
> >    access to IP flow information.  The architecture for the export of
> >    measured IP flow information out of an IPFIX Exporting Process to a
> >    Collecting Process is defined in [RFC5470], per the requirements
> >    defined in [RFC3917].  The IPFIX protocol [RFC5101] specifies how
> >    IPFIX Data Records and Templates are carried via a number of
> >    transport protocols from IPFIX Exporting Processes to IPFIX
> >    Collecting Processes.  IPFIX has a formal description of IPFIX
> >    Information Elements, their names, types, and additional semantic
> >    information, as specified in [RFC5102].  [I-D.ietf-ipfix-mib]
> >    specifies the IPFIX Management Information Base.  Finally, [RFC5472]
> >    describes what types of applications can use the IPFIX protocol and
> >    how they can use the information provided.  It furthermore shows how
> >    the IPFIX framework relates to other architectures and frameworks.
> >    The storage of IPFIX Messages in a file is specified in
> >    [I-D.ietf-ipfix-file].
> > 
> > 3.2.  PSAMP Documents Overview
> > 
> >    The framework for packet selection and reporting [RFC5474] enables
> >    network elements to select subsets of packets by statistical and
> >    other methods and to export a stream of reports on the selected
> >    packets to a Collector.  The set of packet selection techniques
> >    (Sampling, Filtering, and Hashing) standardized by PSAMP are
> >    described in [RFC5475].  The PSAMP protocol [RFC5476] specifies the
> >    export of packet information from a PSAMP Exporting Process to a
> >    Collector.  Like IPFIX, PSAMP has a formal description of its
> >    Information Elements, their names, types and additional semantic
> >    information.  The PSAMP information model is defined in [RFC5477].
> >    [I-D.ietf-psamp-mib] describes the PSAMP Management Information Base.
> 
> 
> > 4.  Problem Statement
> > 
> >    Network administrators generally face the problems of measurement
> >    system scalability, flow-based measurement flexibility, and export
> >    reliability, even if some techniques, such as Sampling, Filtering,
> >    Data Records aggregation and export replication, have already been
> >    developed.  The problems consist of optimizing the resources of the
> >    measurement system while pursuing appropriate conditions: data
> 
> pursuing => fulfilling ?

Yes. 

> 
> >    accuracy, flow granularity, and export reliability.  These conditions
> >    depend on two factors.
> > 
> >    o  measurement systems capacity:
> >       This consists of the bandwidth of the management network, the
> >       storage capacity, and the performances of the collecting devices
> >       and exporting devices.
> > 
> >    o  applications requirements:
> >       Different applications, such as traffic engineering, detecting
> >       anomaly traffic, and accounting, etc., impose different Flow
> 
> traffic anomalies
> 
> >       Record granularity, and data accuracy.
> > 
> >    The recent continued IP traffic growth has been overwhelming the
> 
> "The sustained growth of IP traffic..." ?
> 
> >    measurement system capacity, and multi-purposing applications, along
> 
> multi-purpose?
> 
> Yet, it is not clear to me what you mean.
> 

I means that implementation of multiple traffic measurements, such as
QoS measurement and traffic engineering, have been contributing to a
complex situation, and executing it with the heterogeneous environments
also results in further more complex.

> >    with the heterogeneous environments, have further been contributing
> >    to a complex situation.  The following sub-sections explain different
> >    problems in more details.
> > 
> > 4.1.  Coping with IP Traffic Growth
> > 
> >    Enterprise or service provider networks already have multiple 10 Gb/s
> >    links, their total traffic exceeding 100 Gb/s.  In the near future,
> >    broadband users' traffic will increase by approximately 40% every
> >    year according to [TRAFGRW].  When operators monitor traffic of 500
> >    Gb/s with a Sampling rate of 1/1000, the amount of exported Flow
> >    Records from Exporters could exceed 50 kFlows/s.  This value is
> >    beyond the ability of a single Collector.
> > 
> >    To deal with this problem, current data reduction techniques, such as
> >    Sampling, Filtering, Data Records aggregation have been generally
> 
> For me, "aggregation" refers to the semantic level of exported
> information. Therefore, I would call it "flow aggregation" instead of
> "Data Record aggregation".

Does the flow in "flow aggregation" indicate general 7-tuple flow in
NetFlow? It needs the distinction between flow in NetFlow and Flow in
IPFIX, since the Flow term in IPFIX covers an aggregated Flow.

> 
> >    implemented on Exporters.  Note that Sampling technique leads to
> 
> Sampling technique => packet sampling ?
> 
Yes.

> >    potential loss of small Flows.  With both Sampling and aggregation
> >    techniques, administrators might no longer be able to investigate
> >    very granular traffic change and anomaly detection, both of which can
> 
> "...able to detect and investigate subtle traffic changes and anomalies
> as this requires detailed flow information." ?
> 

Yes.

> >    currently be detected.  With Filtering, only a subset of the Flow
> 
> Data Records
> 
> >    Records are exported.
> > 
> >    Considering the potential drawbacks of Sampling, Filtering, and Data
> >    Records aggregation, there is a need for a large-scale collecting
> >    infrastructure that does not rely on data reduction techniques.
> > 
> > 4.2.  Coping with Multipurpose Traffic Measurement
> > 
> >    A set of conditions (flow granularity and data accuracy) may meet the
> 
> "conditions" does not seem to be an appropriate word.
> 
> >    requirements of some applications, such as traffic engineering, but
> >    may not meet the requirements of other applications, such as
> >    accounting, QoS performance, or even security.  Therefore, with a
> >    single set of conditions, multipurpose traffic measurements cannot be
> >    accomplished.
> >
> >    To cope with the issue, an Exporter needs to export traffic data with
> >    strictest condition (fine flow granularity and high data accuracy)
> >    required by the set of applications.  However, this implies an
> >    increased load on both the Exporter and Collector.
> 
> I would change the whole section to something like:
> 
> "Different monitoring applications, such as ..., impose different
> requirements on the monitoring infrastructure. Some of them require
> traffic monitoring at a flow level while others need information about
> individual packets or just flow aggregates.
> 
> To fulfill these divers requirements, an Exporter would need to perform
> various complex metering tasks in parallel, which is a problem due to
> limited resources. Hence, it can be advantageous to run the Exporter
> with a much simpler setup and to perform appropriate post-processing of
> the exported Data Records at a later stage."
> 

Thanks. It become more clear and concise.

> > 4.3.  Coping with Heterogeneous Environments
> > 
> >    Network administrators use IPFIX Devices and PSAMP Devices from
> >    various vendors, various software versions, various device types
> >    (router, switch, or probe) in a single network domain.  Even legacy
> >    flow export protocols are still deployed in current network.  This
> >    heterogeneous environment leads to differences in Metering Process
> >    capability, Exporting Process capacity (export rate, cache memory,
> 
> capabilities
> 
> >    etc.), and data format.  For example, probes and switches cannot
> >    retrieve packet property information from a route table.
> 
> Do you mean AS information?
> 
Yes. 

"For example, probes and switches cannot retrieve some Derived Packet
Properties in [RFC5102] from a route table."

> >    To deal with this problem, the collecting infrastructure needs to
> >    absorb the differences.  However, equipping all collecting devices
> 
> absorb => mediate?
> 

Yes.

> >    with this absorption function is difficult.
> > 
> > 4.4.  Summary
> > 
> >    In optimizing the resources of a measurement system, it is important
> >    to use traffic data reduction techniques at the possible initial
> 
> "at the possible initial phase" => "as early as possible"
> 

Yes. 

"it is important to use traffic data reduction techniques as early as
possible , e.g., at the Exporter."

> >    phase, e.g., at the Exporter.  However, this implementation is made
> >    difficult by heterogeneous environment of exporting devices.
> > 
> >    This implies that a new Mediation functional block is required in
> 
> Mediation function
> 
> >    typical Exporter-Collector architectures.  Based on some
> >    applicability examples, the next section shows the limitation of the
> >    typical Exporter-Collector architecture model and the IPFIX Mediation
> >    benefits.
> 
> 
> > 5.  Mediation Applicability Examples
> > 
> > 5.1.  Adjusting Flow Granularity
> > 
> >    The simplest types of Flows are those comprised of packets all having
> >    a fixed IP-quintuple of protocol, source and destination IP
> >    addresses, and source and destination port numbers.  However, a
> >    shorter set of Flow Keys, such as a triple, a double, or a single
> >    Flow Key, (for example network prefix, peering AS number, or BGP
> >    Next-Hop fields), creates more aggregated Flow Records.  This is
> >    especially useful for measuring traffic exchange in an entire network
> >    domain and for easily adjusting the performance of Exporters and
> >    Collectors.
> > 
> >    Implementation analysis:
> > 
> >       Implementations for this case depend on where Flow granularity is
> >       adjusted.  More suitable implementations use configurable Metering
> >       Processes in Original Exporters.  The cache in the Metering
> >       Process can specify its own set of Flow Keys and extra fields.
> >       The Original Exporter thus creates directly aggregated Flow
> >       Records.
> > 
> >       In the case where the Original Exporter contains a Metering
> >       Process that creates fixed tuple Flow Records (no possibility to
> >       change the Flow Keys), an IPFIX Concentrator can adjust the Flow
> >       Keys by aggregation Flow Records.  Even if the case where the
> >       Original Exporter contains a Metering Process for which the Flow
> >       Keys can be configured, an IPFIX Concentrator can further
> >       aggregate the Flow Records.
> > 
> > 5.2.  Hierarchical Collecting Infrastructure
> > 
> >    The increase of IPFIX Exporters, the increase of the traffic over
> 
> over => in ?
> 
Yes.

"over large-scale networks" can be removed, since the traffic growth
occurs in any networks. 

> >    large-scale networks, and the variety of treatments expected to be
> >    performed over the Data Records is more and more difficult to handle
> >    within a single Collector.  Hence to increase the collecting (e.g.
> >    the bandwidth capacity) and processing capacity must be distributed
> 
> Something is missing in this sentence. What about:
> "Hence to increase the collecting (e.g., the bandwidth capacity) and
> processing capacity, distributed Collectors must be deployed."
> 

Fine.

> >    over several IPFIX entities.  As a possible approach, a hierarchical
> >    structure is useful for increasing the measurement systems capacity,
> >    both in export bandwidth capacity and in collecting capacity.
> > 
> >    Implementation analysis:
> > 
> >       To cope with the increase of IPFIX Exporters and traffic, one
> >       possible implementation uses IPFIX Concentrators to build a
> >       hierarchical collection system.  To cope with the variety of
> >       treatments, one possible implementation uses IPFIX Distributors to
> >       build a distributed collection system.  More specific cases are
> >       described in section 5.9.
> > 
> > 5.3.  Correlation for Data Records
> > 
> >    The correlation amongst Data Records or between Data record and meta
> 
> Record
> 
> >    data provides new metrics or information, including the following.
> > 
> >    o  One-to-one correlation between Data Records
> > 
> >       *  One way delay and packet arrival interval time etc.  One way
> 
> packet arrival interval time => packet inter-arrival time ?
> 

Yes.

> >          delay from the correlation of Packet Reports from different
> 
> PSAMP Packet Reports?
> 
Yes.

> >          Exporters along a specific path.
> > 
> >       *  Treatment from the correlation of Data Records with the same
> 
> IPFIX Flow Records?
> 

In that case, both of IPFIX Flow Records and PSAMP Packet Reports can be
applied.

> >          Flow Key(s) observed at incoming/outgoing interfaces.  Examples
> >          are the rate-limiting ratio, the compression ratio, the
> >          optimization ratio, etc.
> 
> At the recent TMA workshop, it was proposed to correlate Flow Records
> from ingress and egress routers to determine packet loss on the path
> (A. Friedl et al.: "Realistic Passive Packet Loss Measurement for
> High-Speed Networks")
> 
> This could be another use-case for correlating Flow Records.
> 
It is interesting. It can be considered in future topics about mediation.

> >    o  Correlation amongst Data Records
> > 
> >       Average/maximum/minimum values from correlating multiple Data
> >       Records.  Examples are the average/maximum/minimum packets of
> 
> number of packets of the measured Flows
> 
> >       Flow, the average/maximum/minimum one way delay, the average/
> >       maximum/minimum packet loss, etc.
> 
> number of lost packets
> 
> >    o  Correlation between Data Record and other meta data
> > 
> >       Examples are some BGP attributes associated with Data Record by
> >       looking up routing table.
> 
> the routing table ?
> 
Yes.

> >    Implementation analysis:
> > 
> >       One possible implementation for the case uses an IPFIX
> 
> this case
> 
> >       Concentrator located between the Metering Processes and Exporting
> >       Processes on the Original Exporter, or alternatively a separate
> >       IPFIX Concentrator located between the Original Exporters and
> >       IPFIX Collectors.
> > 
> > 5.4.  Time Composition
> > 
> >    Time composition is defined as the aggregation of consecutive Data
> 
> in this case: IPFIX Flow Records
> 

Aggregation (including the Time composition) can be applied to both of
input IPFIX Flow Records and input PSAMP Packet Reports. Hence, this
case keeps "Data Records".

> >    Records with identical Flow Keys.  It leads to the same output as
> >    setting a longer active interval timer on Original Exporters with one
> >    advantage: the creation of new metrics such as average, maximum and
> >    minimum values from Flow Records with a shorter time interval enables
> >    administrators to keep track of changes that might have happened
> >    during the time interval.
> > 
> >    Implementation analysis:
> > 
> >       One possible implementation for this case uses an IPFIX
> >       Concentrator located between the Metering Processes and Exporting
> >       Processes on the Original Exporter, or alternatively as a separate
> 
> remove "as"
> 
> >       IPFIX Concentrator located between the Original Exporters and
> >       IPFIX Collectors.
> > 
> > 5.5.  Spatial Composition
> > 
> >    Spatial composition is defined as the aggregation of Data Records in
> >    a set of Observation Points within an Observation Domain, across
> >    multiple Observation Domains from a single Exporter, or even across
> >    multiple Exporters.  The spatial composition is divided into four
> >    types.
> > 
> >    o  Case 1: Spatial Composition within one Observation Domain
> > 
> >       For example, in the case where a link aggregation exists, Data
> >       Records observed at physical interfaces belonging to the same
> 
> You do not "observe" Data Records. Maybe:
> "...Data Records with information measured at..."
> 

Thanks.

> >       trunk can be merged.
> > 
> >    o  Case 2: Spatial Composition across Observation Domains, but within
> >       a single Exporter
> > 
> >       For example, in the case where a link aggregation exists, Data
> >       Records observed at physical interfaces belonging to a same trunk
> 
> "...Data Records with information measured at..."
> 
> >       grouping beyond the line interface module can be merged.
> > 
> >    o  Case 3: Spatial Composition across Exporters
> > 
> >       Data Records observed within an administrative domain, such as the
> 
> "...Data Records with information measured at..."
> 
> >       west area and east area of an ISP network, can be merged.
> > 
> >    o  Case 4: Spatial Composition across administrative domains
> > 
> >       Data Records observed across administrative domains, such as
> 
> "...Data Records with information measured at..."
> 
> >       across different customer networks or different ISP networks, can
> >       be merged.
> > 
> >    Implementation analysis:
> > 
> >       One possible implementation for the case 1 and 2 uses an IPFIX
> 
> cases
> 
> >       Concentrator located between the Metering Processes and Exporting
> >       Processes on the Original Exporter.  A separate IPFIX Concentrator
> >       located between the Original Exporters and IPFIX Collector is a
> >       valid solution for the case 1, 2, 3, and 4.
> 
> cases
> 
> > 5.6.  Data Record Anonymization
> > 
> >    IPFIX exports across administrative domains can be used to measure
> >    traffic for wide-area traffic engineering or to analyze Internet
> >    traffic trends, as described in the Spatial Composition across
> 
> as described in the previous subsection on "spacial composition across
> administrative domaines".
> 
Yes.

> >    administrative domains in the previous subsection.
> >    In such case, administrators need to adhere to privacy protection
> 
> In such a case...
> 
> >    policies and prevent access to confidential traffic measurements by
> >    other people.  Typically, anonymization techniques enables the
> >    provision of traffic data to other people without violating these
> >    policies.
> > 
> >    Generally, anonymization modifies a data set to protect the identity
> >    of the people or entities described by the data set from being
> >    disclosed.  It also attempts to preserve sets of network traffic
> >    properties useful for a given analysis while ensuring the data cannot
> >    be traced back to the specific networks, hosts, or users generating
> >    the traffic.  For example, IP address anonymization is particularly
> >    important for avoiding the identification of the users, hosts, and
> >    routers.
> > 
> >    Implementation analysis:
> > 
> >       One possible implementation for this case uses an anonymization
> >       function at the Original Exporter.  However, this increases the
> >       load on the Original Exporter.  A more flexible implementation
> >       uses a separate IPFIX Masquerading Proxy between the Original
> >       Exporter and Collector.
> > 
> > 5.7.  Data Retention
> > 
> >    Data retention refers to the storage of traffic data by service
> >    providers and commercial organizations.  Network administrators
> 
> administrators => operators ?
> 
Yes.

> >    should retain both IP and voice traffic data, in wired and wireless
> 
> "should retain" sounds like "SHOULD retain", which is definitively not
> what we want to specify in an IETF standard.
> 
> Better something like: "Legislative regulations often require that
> network operators retain..."

Good idea.
> 
> What do you mean by "voice traffic data"?
> As far as I known, records of VoIP connections are to be retained, but
> not the voice data.
> 
> I assume that wiretapping telephone calls must be explicitly requested
> by a judge in must democratic countries. It does not fall under the
> general data retention policies.

Thank you for your advices.

I intend the Call Detail Records including caller number, callee number,
call duration and start time for the session, not wiretapping. The
sentence can be modified as follows.

"Legislative regulations often require that network operators retain
both IP traffic data and call detail records, in wired and wireless
networks, generated by end users while using a service provider's
services."

> 
> >    networks, generated by end users while using a service provider's
> >    services.  The traffic data is required for the purpose of the
> >    investigation, detection and prosecution of serious crime, if
> >    necessary.  Data retention services examples are the following:
> > 
> >    o  Fixed telephony (includes fixed voice calls, voicemail, and
> >       conference and data calls)
> > 
> >    o  Mobile telephony (includes mobile voice calls, voicemail,
> >       conference and data calls, SMS, and MMS)
> > 
> >    o  Internet telephony (includes every multimedia session associated
> >       with IP multimedia services)
> > 
> >    o  Internet e-mail
> > 
> >    o  Internet access
> > 
> >    Data retention for Internet access services in particular requires a
> >    measurement system with reliable export and huge storage as the data
> >    must be available for a long period of time, typically a couple of
> >    years.
> 
> A couple of years sounds unrealistic. As far as I know, it's six months
> in the EU.  Longer retention times are usually prevented by privacy laws.

I will rephrase it with "typically at least six months". 

Wikipedia say that a period is between 6 months and 2 years.
http://en.wikipedia.org/wiki/Telecommunications_data_retention

> 
> >    Implementation analysis:
> > 
> >       Regarding export reliability requirement, the most suitable
> >       implementation uses the SCTP transport protocol between the
> >       Original Exporter and Collector.  If a unreliable transport
> 
> an unreliable
> 
> >       protocol such as UDP is used, a legacy exporting device exports
> >       Data Records to a nearby IPFIX Proxy through UDP, and then an
> >       IPFIX Proxy could reliably export them to the top IPFIX Collector
> >       through SCTP.  If a unreliable transport protocol such as UDP is
> >       used and if there is no IPFIX Proxy, the legacy exporting device
> >       must duplicate the exports to several Collectors.
> 
> I would remove the last sentence. Losses are provoked by congestion.
> Doubling the exported data increases the risk of congestion.
> 

Yes.

> >       Regarding huge storage requirement, one possible implementation
> >       uses a decentralized set of Collectors.  If administrators need to
> >       retrieve specific Data Records, these Collectors would need to be
> >       equipped with IPFIX Mediations.
> > 
> > 5.8.  IPFIX Export from a Branch Office
> > 
> >    Generally, in large enterprise networks, Data Records from branch
> >    offices are gathered in a central office.  However, in the long
> >    distance branch office case, the bandwidth for transport IPFIX is
> >    limited.  Therefore, even if multiple Flow Records type should be of
> 
> Data Record types?
> 
Yes.

> >    interest to the Collector (Flow Records in both directions, Flow
> 
> "(e.g., IPFIX Flow Records for both directions,...)"
> 
> >    Records before and after WAN optimization techniques, performance
> >    metrics associated with the Flow Records exported on regular
> >    interval), the export bandwidth limitation is an important factor to
> >    pay attention to.
> > 
> >    Implementation analysis:
> > 
> >       One possible implementation for the case uses an IPFIX
> 
> this case
> 
> >       Concentrator located in a branch office.  The IPFIX Concentrator
> >       would aggregate and correlate Flow Records to cope with the export
> 
> Data Records?
> 
Yes.

> >       bandwidth limitation.
> > 
> > 5.9.  Distributing Data Records
> > 
> >    Recently, several networks have shifted towards integrated networks,
> >    such as the pure IP and MPLS, which includes IPv4, IPv6, and VPN
> 
> "pure IP and MPLS networks"?
> 
Yes.

> >    traffic.  Data Record types (IPv4, IPv6, MPLS, and VPN) need to be
> >    analyzed separately and from different perspectives for different
> >    organizations.  A single Collector handling all Data Record types
> >    might become a bottleneck in the collecting infrastructure.  Data
> >    Records distributed based on their respective types can be exported
> >    to the appropriate Collector, resulting in the load distribution
> >    amongst multiple Collectors.
> > 
> >    Implementation analysis:
> > 
> >       One possible implementation for this case uses the replications of
> >       the IPFIX Message in an Original Exporter for multiple IPFIX
> >       Collectors.  Each Collector then extracts the Data Record required
> >       by its own applications.  However, the replication increases the
> >       load of the Exporting Process and the waste of the bandwidth
> >       between the Exporter and Collector.
> > 
> >       A more sophisticated implementation uses an IPFIX Distributor
> >       located between the Metering Processes and Exporting Processes in
> >       an Original Exporter.  The IPFIX Distributor determines
> >       respectively to which Collector a Data Record is exported by
> 
> remove "respectively"?
> 
> >       filtering certain field values.  If a Original Exporter does not
> 
> "by filtering..." => "depending on certain field values"
> 

Yes.

> >       have IPFIX Distributor capability, it exports Data Records to a
> >       nearby separate IPFIX Distributor, and then the IPFIX Distributor
> >       could distribute them to the appropriate IPFIX Collectors.
> > 
> >       For example, in the case of distributing a specific customer's
> >       Data Records, an IPFIX Distributor needs to identify the customer
> >       networks.  The Route Distinguisher (RD), ingress interface,
> >       peering AS number, or BGP Next-Hop, or simply the network prefix
> >       may be evaluated to distinguish different customer networks.  In
> >       the following figure, the IPFIX Distributor reroutes Data Records
> >       on the basis of the RD value.  This system enables each customer's
> >       traffic to be inspected independently.
> > 
>  >                                                .---------.
> >                                                |Traffic  |
> >                                          .---->|Collector|<==>Customer#A
> >                                          |     |#1       |
> >                                          |     '---------'
> >                                       RD=100:1
> >     .----------.        .-----------.    |
> >     |IPFIX     |        |IPFIX      |----'     .---------.
> >     |Exporter#1|        |Distributor| RD=100:2 |Traffic  |
> >     |          |------->|           |--------->|Collector|<==>Customer#B
> >     |          |        |           |          |#2       |
> >     |          |        |           |----.     '---------'
> >     '----------'        '-----------'    |
> >                                       RD=100:3
> >                                          |     .---------.
> >                                          |     |Traffic  |
> >                                          '---->|Collector|<==>Customer#C
> >                                                |#3       |
> >                                                '---------'
> > 
> >       Figure A: Distributing Data Records to Collectors using IPFIX
> >       Distributor
> > 
> > 5.10.  Flow-based Sampling and Selection
> > 
> >    Generally, the distribution of the number of packets per Flow seems
> >    to be heavy-tailed.  Most types of Flow Records are likely to be
> >    small Flows consisting of a small number of packets.  The measurement
> >    system is overwhelmed with a huge amount of these small Flows.  If
> >    statistics information of small Flows is exported as merged data by
> >    applying a policy or threshold, the load on the Exporter is reduced.
> >    Furthermore, if the flow distribution is known, exporting only a
> >    subset of the Data Records might be sufficient.
> > 
> >    Implementation analysis:
> > 
> >       One possible implementation for this case uses an IPFIX
> >       Concentrator located between the Metering Processes and Exporting
> >       Processes on the Original Exporter, or alternatively as a separate
> >       IPFIX Concentrator located between the Original Exporters and
> >       IPFIX Collectors.  A set of IPFIX Mediation functions, such as
> >       filtering, selecting and aggregation is used in the IPFIX
> 
> Filtering, Sampling ?
> 

Yes.

> >       Concentrator.
> > 
> > 5.11.  Interoperability between Legacy Protocols and IPFIX
> > 
> >    During the migration process from a legacy protocol such as NetFlow
> >    [RFC3954] to IPFIX, both NetFlow exporting devices and IPFIX
> >    Exporters are likely to coexist in the same network.  Operators need
> >    to continue measuring the traffic data from legacy exporting devices,
> >    even after introducing IPFIX Collectors.
> > 
> >    Implementation analysis:
> > 
> >       One possible implementation for this case uses an IPFIX Proxy that
> >       converts a legacy protocol to IPFIX.
> 
> 
> > 6.  IPFIX Mediators Implementation Specific Problems
> > 
> > 6.1.  Loss of Original Exporter Information
> > 
> >    Both the Exporter IP address indicated by the source IP address of
> >    the IPFIX Transport Session and the Observation Domain ID included in
> >    the IPFIX Message header are likely to be lost by an IPFIX Mediator
> 
> "lost during IPFIX Mediation."?
> 
Yes.

> >    such as IPFIX Concentrator too.  In some cases, a IPFIX Masquerading
> 
> remove "such as IPFIX Concentrator"
> 
Yes.
> >    Proxy might drop the information.  In other cases, the Collector must
> 
> "...might drop the information deliberately" ?
> 
Yes.

> >    recognize the Original Exporter (and potentially the Observation
> >    Domain and Observation Point as well) whether Data Records go through
> 
> rephrase:
> "In general, however, the Collector must recognize the origin of the
> measurement information, such as the IP address of the Original
> Exporter, the Observation Domain ID, or even the Observation Point ID."
> 

Yes, indeed.

> >    an IPFIX Mediator or not.  Note that, if the Mediator can not
> >    communicate the Original Exporter IP address, then the top level
> >    Collector will wrongly deduce that the IP address of the IPFIX
> >    Mediator is that of the Original Exporter.
> > 
> >    In the following figure, a Collector can identify two IP addresses:
> >    10.1.1.3 (IPFIX Mediator) and 10.1.1.2 (Exporter#2), respectively.
> >    The Collector, however, needs to somehow recognize both Exporter#1
> >    and Exporter#2, which are the Original Exporters.  The IPFIX Mediator
> >    must have a specific way to the Original Exporter IP address to the
> 
> "must be able to notify the Collector about the IP address of the
> Original Exporter."
> 

Yes.

> >    IPFIX Collector.
> > 
> >    .----------.          .--------.
> >    |IPFIX     |          |IPFIX   |
> >    |Exporter#1|--------->|Mediator|---+
> >    |          |          |        |   |
> >    '----------'          '--------'   |      .---------.
> >    IP:10.1.1.1         IP:10.1.1.3    '----->|IPFIX    |
> >    ODID:10             ODID:0                |Collector|
> >                                       +----->|         |
> >    .----------.                       |      '---------'
> >    |IPFIX     |                       |
> >    |Exporter#2|-----------------------'
> >    |          |
> >    '----------'
> >    IP:10.1.1.2
> >    ODID:20
> > 
> >    Figure B: Loss of Original Exporter Information.
> > 
> > 6.2.  Loss of Base Time Information
> > 
> >    The Export Time field included in the IPFIX Message header indicates
> >    the base time for Data Records.  IPFIX Information Elements,
> 
> "...indicates the base time" => "...represents a reference timestamp..."
> 
> " _Some_ IPFIX Information Elements..."
> 
> >    described in [RFC5102], have delta time fields that indicate the time
> 
> "have delta time fields" => "carry delta timestamps" ?
> 
Yes.

> >    difference from the value of the Export Time field.  If the Data
> >    Records include any delta time fields and the IPFIX Mediator
> >    overwrites the Export Time field when sending IPFIX Messages, the
> >    delta time fields become meaningless and, because Collectors cannot
> >    recognize this situation, wrong time values are propagated.
> > 
> > 6.3.  Transport Sessions Management
> > 
> >    Maintaining relationships between the incoming Transport Sessions and
> >    the outgoing ones depends on the Mediator's implementation.  If
> 
> Better:
> "If an IPFIX Mediator relays multiple incoming Transport Sessions to a
> single outgoing Transport Session, ..."
> 

Yes.

> >    multiple incoming Transport Sessions are relayed to a single outgoing
> >    Transport Session, and if the IPFIX Mediators shuts down its outgoing
> >    Transport Session, Data Records on other incoming Transport Sessions
> 
> "... Data Records of the incoming Transport Sessions would not be
> relayed any more."
> 
> >    would not be relayed at all.  In the case of resetting of an incoming
> 
> remove "of"
> 
> >    session, the behavior of the IPFIX Mediator needs to be specified.
> > 
> > 6.4.  Loss of Option Template Information
> > 
> >    In some cases, depending on the implementation of the IPFIX
> >    Mediators, the information that is reported by the Option Templates
> 
> "...reported in the Data Records defined by Option Templates..."

Yes, indeed.
> 
> >    could also be lost.  If, for example, the Sampling rate is not
> >    communicated from the Mediator to the Collector, the Collector would
> >    miscalculate the traffic volume.  This might lead to crucial
> >    problems.  Even if an IPFIX Mediator was to simply relay received
> >    Option Template Information, the values of its scope fields could
> 
> "Option Data Records"? Yet this is not an official term either.
> 
I can rephrase it, as follows.
"... received Data Records defined by Options Templates, the values of
its scope fields could..."

> >    become meaningless in the context of a different Transport Sessions.
> >    The minimal information to be communicated by an IPFIX Mediator must
> >    be specified.
> > 
> > 6.5.  Template ID Management
> > 
> >    The Template ID is unique on the basis of the Transport Session and
> >    Observation Domain ID.  If Mediations are not able to manage the
> 
> "Mediations are" => "IPFIX Mediation is"
> 
Yes.

> >    relations amongst the Template IDs and the incoming Transport Session
> >    information, and if the Template ID is used in the Options Template
> >    scope, the Mediators would, for example, relay wrong values in the
> 
> "the Mediators" => "IPFIX Mediators"
> 
Yes.
> >    scope field and in the Template Withdrawal Message.  The Collector
> >    would thus not be able to interpret the Template ID in the Template
> >    Withdrawal Message and in the Options Template scope.  As a
> >    consequence, there is a risk that the Collector would then shut down
> >    the IPFIX Transport Session.
> > 
> >    For example, an IPFIX Distributor must maintain the state of the
> >    incoming Transport Sessions in order to manage the Template ID on its
> >    outgoing Transport Session correctly.  In the following figure, even
> 
> The rest of the paragraph is unclear:
> 
> >    if the Transport Session from Exporter re-initializes, the IPFIX
> >    Distributor must manage the association of Template IDs in specific
> >    Transport Session.  Typically, when the Exporter#1 Transport Session
> >    re-initialized, the Template ID 256 replaced the previous Template ID
> >    258, while the IPFIX Distributor will keep exporting the Template ID
> >    256 to the Collector.
> 
> Are all Templates identical? Or how comes that there is only one
> Template in the outgoing Transport Session?
> 
> Please explain better.
> 

I image that IPFIX Distributor exports 3 templates including
template ID 256, template ID 257, and template ID 258. All templates are
kept the template ID value from input Transport Session. Even when the
Exporter 1 is re-initialized and the template 258 is replaced with 256, IPFIX
Distributor must avoid the duplication of template ID values.

I will improve the phrase and the following figure.

> > 
> > 
> >    .----------. OLD: Template ID 258
> >    |IPFIX     | NEW: Template ID 256
> >    |Exporter#1|----+
> >    |          |    |
> >    '----------'    X
> >    .----------.    |           .-----------.               .----------.
> >    |IPFIX     |    '---------->|           |               |          |
> >    |Exporter#2|--------------->|IPFIX      |-------X------>|IPFIX     |
> >    |          |Template ID 257 |Distributor|Template ID 256| Collector|
> >    '----------'    +---------->|           |               |          |
> >    .----------.    |           '-----------'               '----------'
> >    |IPFIX     |    |
> >    |Exporter#3|----'
> >    |          | Template ID 256
> >    '----------'
> > 
> >    Figure C: Relaying from Multiple Transport Sessions to Single
> >    Transport Session.
> > 
> > 6.6.  Consideration for Network Topology
> > 
> >    While IPFIX Mediation can be applied anywhere, caution should be
> >    taken as how to aggregate the counters, as there is a potential risk
> >    of double-counting.  For example, if three Exporters export Flow
> >    Records related to the same Flow, the one-way delay can be
> >    calculated, while the summing up the number of packets and bytes does
> >    not make sense.  Alternatively, if three Exporters export Flow
> 
> Howerver, we could calculate packet losses on the path. See comment above.
> 
Yes. The subtracting the number of packets might result in loss packets.

> >    Records entering an administrative domain, then the sum of the
> >    packets and bytes is a valid operation.  Therefore, the possible
> >    function to be applied to Flow Records must take into consideration
> >    the measurement topology.  The information such as the network
> >    topology, or at least the Observation Point and measurement
> >    direction, is required on the IPFIX Mediation.
> 
> "on the" => "for" ?
> 
> > 6.7.  Exporting the Function Item
> > 
> >    In some case, the top IPFIX Collector needs to recognize which
> 
> remove "top"? I know what you mean, but it does not have to be clear to
> all readers.
> 
Yes.

> >    specific function(s) the IPFIX Mediation has executed on the Data
> >    Records.  The IPFIX Collector cannot distinguish between Time
> >    Composition, Spatial Composition, and Flow Key aggregation, if the
> >    IPFIX Mediator does not export the applied function.  Some parameters
> >    related to the function also would need to be exported.  For example,
> >    in case of Time Composition, the active time of original Flow Records
> >    is required to interpret the minimum/maximum counter correctly.  In
> >    case of Spatial Composition, spatial area information on which Data
> >    Records is aggregated is required.
> > 
> > 6.8.  Consideration for Aggregation
> > 
> >    In case of Flow Key aggregation, Time Composition, and Spatial
> >    Composition, there are the following considerations:
> > 
> >    o  Aggregation rule for non Flow Keys
> 
> "non Flow Keys" => "non-key fields"
> 
> >       There are no obvious rules of non Flow Keys.  For example, if an
> 
> "non Flow Keys" => "non-key fields"
> 
> >       IPFIX Mediation receives two Flow Records with different DSCP
> >       values, and this DSCP field is not a Flow Key, those two Flow
> >       Records can be aggregated based on the Flow Keys value.  However,
> >       there is no rules for what the DSCP value should be for the
> >       aggregated Data Record.  Potential solutions are: the value of
> 
> Actually, there is a rule!
> Unless specified differently, the value of the first packet must be
> included in the record. Hence, as long as timestamps are present and
> allow to determine which one of the Flow Records includes the earliest
> packet, the decision is evident!
> 

I don't undestand your points.

If receiving two Flow Records ( earlier one with DSCP=1 and later one
with DSCP=2), we can choose the several implementations as follows.
- DSCP=1, keeping the earliest value
- DSCP=2, overwriting the latter value
- DSCP=0, setting the 0 values, when finding unmatch in DSCP field.
- deleting DSCP field from data structure

In my opinion, the topic seem not require the rule of non-key fields.
But, it needs the discussion in next phase, not in problem statement
phase. Even if the conclusion of discussion is no need of the rule, I
expect that some document (maybe IPFIX aggregation) describes that
non-key fields might result in ambiguous value.

> >       single of the two DSCP, the value 0 (in this case, the value 0 is
> >       a valid DSCP value), or removing a DSCP field in its Data Record.
> > 
> >    o  Configured Selection Fraction on aggregation
> > 
> >       There is no obvious rules of how to compute Configured Selection
> >       Fraction, and whether a Mediator should report Configured
> 
> remove ", and whether....,"
> It is obvious, that Configured or Attained Selection Fraction is
> necessary to interpret the Flow Records.
> 
> 
> >       Selection Fraction, when aggregation resulting from Sampling.  For
> 
> "...when aggregating IPFIX Flow Records of sampled packets."
> 
Yes.

> >       example, special care must be taken in the following: aggregation
> >       resulting from the different Configured Selection Fraction,
> >       aggregation resulting from different Sampling techniques, such as
> >       Systematic Count-Based Sampling and Random n-out-of-N Sampling
> >       etc.
> 
> 
> > 7.  Summary and Conclusion
> > 
> >    This document described the problems that network administrators have
> >    been facing, the applicability of IPFIX Mediation to these problems,
> >    and the problems related to the implementation of IPFIX Mediators.
> >    To assist the operations of the Exporters and Collectors, there are
> >    various IPFIX Mediations from which the administrators may select.
> >    Examples of the applicability of IPFIX Mediation are as follows.
> > 
> >    o  Regarding large-scale measurement system, IPFIX Concentrators or
> >       IPFIX Distributors help to achieve traffic analysis with high data
> >       accuracy and fine flow granularity even as IP traffic grows.  As
> >       IPFIX Mediation capabilities, Flow selection Sampling,
> 
> flow sampling?
> 
Yes.

> >       aggregation, and composition are effective.
> > 
> >    o  Regarding data retention, IPFIX Mediators enhance the export
> >       reliability, and the storage of the measurement system.
> > 
> >    o  Regarding the distribution of Data Records, IPFIX Distributors
> >       help to achieve multipurpose traffic analysis for different
> >       organizations, or help to achieve respective traffic analysis
> >       based on Data Record types(IPv4, IPv6, MPLS, and VPN).
> > 
> >    o  Regarding IPFIX Exporting across domains, IPFIX Masquerading
> 
> exporting
> 
Yes.

> >       Proxies help administrators to anonymize or filter Flow Records/
> 
> Data Records
> 
Yes.

> >       Packet Reports, preventing privacy violations.
> > 
> >    o  Regarding interoperability, IPFIX Proxies provide interoperability
> >       between legacy protocols and IPFIX, even during the migration
> >       period to IPFIX.
> > 
> >    As a result, the IPFIX Mediation benefits become apparent.  However,
> >    there are still some open issues with the use of IPFIX Mediators.
> > 
> >    o  Both Observation Point and IPFIX Message header information, such
> >       as the Exporter IP address, Observation Domain ID, and Export Time
> >       field, might be lost.  This data should therefore be communicated
> >       between the Original Exporter and Collector via the IPFIX
> >       Mediator.
> > 
> >    o  IPFIX Mediators are required to manage Transport Sessions,
> >       Template IDs, and Observation Domain IDs.  Otherwise, anomalous
> >       IPFIX messages could be created.
> > 
> >    o  Data advertised by Option Templates from the Original Exporter,
> 
> _Options_ Templates
> 
> better:
> "Options Data Records exported by the Original Exporter, such as those
> reporting the Sampling rate...."
> 
> Maybe the term "Options Data Record" should be introduced to simplify
> things. BTW, we had the same problem in per-sctp-stream, and always
> wrote "Data Record defined by an Options Template Record", which is not
> very easy to read.
> 

Yes, indeed. I hope the term is defined in another document, not problem
statement. The problem statement does not suit.

> >       such as the Sampling rate and Sampling algorithm used, might be
> >       lost.  If a Collector is not informed of current Sampling rates,
> >       traffic information might become worthless.
> > 
> >    These problems stem from the fact that no standards regarding IPFIX
> >    Mediation have been set.  In particular, the minimum set of
> >    information that should be communicated between Original Exporters
> >    and Collectors, the management between different IPFIX Transport
> >    Sessions, and the internal components of IPFIX Mediators should be
> >    standardized.
> 
> 
> > 8.  Security Considerations
> > 
> >    A flow-based measurement system must prevent potential security
> >    threats: the disclosure of confidential traffic data, injection of
> >    incorrect data, and unauthorized access to traffic data.  These
> >    security threats of the IPFIX protocol are covered by the security
> >    considerations section in [RFC5101] and are still valid for IPFIX
> >    Mediators.
> > 
> >    And a measurement system must also prevent following security threats
> 
> "...the following..."
> 
> >    related to IPFIX Mediation:
> > 
> >    o  Attacks against IPFIX Mediator
> > 
> >       IPFIX Mediators can be considered as a prime target for attacks,
> >       as an alternative to IPFIX Exporters and Collectors.  IPFIX
> >       Proxies or Masquerading Proxies need to prevent unauthorized
> >       access or denial-of-service (DoS) attacks from untrusted public
> >       networks.
> > 
> >    o  Man-in-the-middle attack by untrusted IPFIX Mediator
> > 
> >       The Collector-Mediator-Exporter structure model would increase the
> >       risk of the man-in-the-middle attack.
> > 
> >    o  Configuration on IPFIX Mediation
> > 
> >       In the case of IPFIX Distributors and IPFIX Masquerading Proxies,
> >       an accidental misconfiguration and unauthorized access to
> >       configuration data could lead to the crucial problem of disclosure
> >       of confidential traffic data.
> 
> 
> -- 
> Dipl.-Ing. Gerhard M〓z
> Chair for Network Architectures and Services (I8)
> Department of Informatics
> Technische Universit舩 M〓chen
> Boltzmannstr. 3, 85748 Garching bei M〓chen, Germany
> Phone:  +49 89 289-18008       Fax: +49 89 289-18033
> E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz
> 
> 

--- 
Atsushi KOBAYASHI  <[email-masked]>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637

---

From: Atsushi Kobayashi <[email-masked]>
Date: Wed, 10 Jun 2009 21:53:53 +0900

Dear Juergen,

Sorry for late reply.

> * 6.8:
> 
> I am not how to read 'when aggregation resulting from Sampling' in
> this sentence:
> 
>       Selection Fraction, when aggregation resulting from Sampling.
> 

I indicate that there is no obvious rules in case of aggregation for
Flow Records resulting from packet sampling.

In case of aggregation for Flow Records from different Exporters with
same sampling interval, or with different sampling interval, we need to
discuss need of Configured Selection Fraction, and discuss how to compute
it in next phase.

I will improve the sentences.

Regards,
Atsushi KOBAYASHI

> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

---

From: Gerhard Muenz <[email-masked]>
Date: Sun, 14 Jun 2009 12:33:42 +0200

Dear Atsushi, all,

Actually, I was surprised and a little bit disappointed that Jürgen and
me were the only ones who answered to the WGLC - or did I miss something?

Even though this is "only" an informational problem statement, I think
it would be useful to have more reviewers and more discussion.
Otherwise, it looks like a lack of interest in IPFIX mediation - and no
interest means that there is no need for a standard.

> defined as the devices, I think that the following issues can be solved.

Yes, I think that IPFIX Concentrator, Proxy, etc. should be defined as
devices. IPFIX Mediator can be an umbrella term for all of them.

This change will result in a couple of further changes in the text.
E.g. in the introduction:
    While the IPFIX requirements defined in [RFC3917] mention an
    _intermediate function_, such as an IPFIX Proxy or an IPFIX
    Concentrator, there are no documents defining the function called
    IPFIX Mediation.
"intermediate function" needs to be replaced, e.g. by "device"?

> Yes. We can describe the your suggestion as "Intermediate Process" in

Ok.

>>>    to a complex situation.  

Ok, so maybe two sentences:
"The sustained growth of IP traffic has been overwhelming measurement
system capacities. Furthermore, a large variety of applications (e.g.,
QoS measurement, traffic engineering, security monitoring) and the
deployment of IP traffic measurements in heterogeneous environments have
been increasing the demand and complexity of IP traffic measurements."

>>> The following sub-sections explain different

Well, to what kind of aggregation do you want to refer in this sentence?
What kind of aggregation is currently implemented apart from flow
aggregation in the sense of aggregating 7-tuple flows?

To be more general, you could write:
"To deal with this problem, current data reduction techniques, such as
Sampling, Filtering, aggregation of measurement data,..."

> Properties in [RFC5102] from a route table."

"..., such as the autonomous systems of source and destination IP
addresses." ?

> In that case, both of IPFIX Flow Records and PSAMP Packet Reports can be

Hm, Packet Reports do not have "Flow Key(s)" as mentioned in the
sentence, do they?

> case keeps "Data Records".

Same as above: PSAMP Packet Reports does not have Flow Key(s).
So, the sentence only works for Flow Records.

> Distributor must avoid the duplication of template ID values.

The mapping of incoming Template IDs to outgoing Template IDs is not
clear from the figure. Maybe a table would help to explain.
And again: Exporter 1's Templates 256 and 258 are identical, right?

> - DSCP=1, keeping the earliest value

This is the correct solution!

Because RFC5102 says:
   "For Information Elements with values
   that are derived from fields of packets or from packet treatment and
   for which the value may change from packet to packet within a single
   Flow, the IPFIX information model defines that their value is
   determined by the first packet observed for the corresponding Flow,
   unless the description of the Information Element explicitly
   specifies a different semantics."

> - DSCP=0, setting the 0 values, when finding unmatch in DSCP field.

These two options lead to invalid field value according to RFC5102.

> - deleting DSCP field from data structure

This is also possible.

> non-key fields might result in ambiguous value.

There is no need for a new rule because RFC 5102 already specifies what
needs to be done!

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz

---

From: Atsushi Kobayashi <[email-masked]>
Date: Mon, 15 Jun 2009 19:02:47 +0900

Dear Gerhard, and all,

> me were the only ones who answered to the WGLC - or did I miss something?

I have received comments from the Juergen and you. It is too few. :-(
I expect the other members did not send a message yet in list.

> interest means that there is no need for a standard.

Gerhard, thank you.

Anyone's comments are welcome.
Let me know your comments and feedback. 

> "intermediate function" needs to be replaced, e.g. by "device"?

Oh, yes.

> been increasing the demand and complexity of IP traffic measurements."

Yes. fine.

> aggregation in the sense of aggregating 7-tuple flows?

Currently, we can use implemented NetFlow version 8 or flexible
aggregation based on NetFlow version 9. As you mention, I should
describe it more generally.

> So, the sentence only works for Flow Records.

OK.

I can use "defined common properties" instead of "Flow Key(s)" to apply
to the Flow and Packet Report.

Yes.

>    specifies a different semantics."

Uhm, I missed the description on RFC5102.
It is determined by first packet. It might indicate determining by first
received Flow Record. I wonder that first received Flow Record might not
have the exact value of the first observed packet. In case of
mediation, especially the spatial composition, the Flow Records are
collected from a several observation points, it would be difficult to
assure the exact value.

Although this section needs to be rewritten, the topic will need to discuss
at the later stage after problem statement.

> There is no need for a new rule because RFC 5102 already specifies what

I am not sure just RFC5102 can be applied to mediation.

I will discuss it with co-authors. Thank you!

Best Regards,
Atsushi KOBAYASHI

---

From: Atsushi Kobayashi <[email-masked]>
Date: Tue, 16 Jun 2009 18:39:24 +0900

Shindo-san,

Thank you!

Please see commments inline.

On Tue, 16 Jun 2009 15:28:45 +0900 (JST)
Motonori Shindo <[email-masked]> wrote:

> Atsushi,
> 
> I went through the draft-ietf-ipfix-mediators-problem-statement-03 and
> came up with some comments and questions as follows:
> 
>                                                  ^^^^^^^^^^^
> Here you refer to it as a "route table" while referring to the same
> thing as "routing table" in another place. It's better to be
> consistent. I personally prefer "routing table".

Ok. I unify into reference "routing table".

> >    addresses, and source and destination port numbers.  
> 
> This is a bit cosmetic point, but I think 5-tuple (src/dst ip address,
> src/dst port number and transport protocol) is more widely accepted as
> a flow than the quintuple you mentioned.
> 

You are right. 5-tuple is more preferable. 

> >       change the Flow Keys), ...                        ^^^^^^^^^^^
> 
> You probably meant "ability" ?
> 
Yes.

> >    setting a longer active interval   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> 
> "It has the same effect" is more intuitive for me.
> 
> I would like to point out that ifIndex (ingressInterface and
> egressInterface) can sometimes be subject to anonymization. Suppose an
> ISP is providing a traffic monitoring service to end customers who
> have their own IPFIX Collector. In such a case, ISP might not wish to
> disclose the interface information of their routers/switches to end
> customers even if it is simply an integer value.
> 

Good example. A whole set of integer values related to ifIndex might be
fingerprint of routers, or switches. Someone can deduces its vendor, or
software version.

> IPFIX Proxy best fits into this situation, where ifIndex information
> is anonymized or even completely suppressed. 
> 

It is IPFIX Masquerading Proxy. ;-)

I will add the following sentence.

"As another example, when ISP provides a traffic monitoring service to
end customers by their own Exporters, even in case of exporting
interface index fields, network administrators take care of anonymizing
its fields to avoid disclosing the vulnerability."

> >       through SCTP.                                 ^^^^^^^^^^^^^^^^^^^
> 
> This is the first occurrence of the concept "top" for Collectors and
> there are a few more places referring to the same concept (e.g. "top
> level Collector"). It should be clearly defined before you refer to
> this concept.
> 

As Gerhalz pointed out, I will remove "top" and "top level". 

> I don't quite understand this paragraph. Will you be a bit more
> elaborate?
> 

One possible implementation adopts distributed structure of Collectors
to increase the storage capacity. Example is a parallel structure in
which Collectors are located near Exporters.

If some application servers need to communicate with these Collectors, these
Collectors would have the IPFIX Mediation.

> >    interval), 
> Appending ", etc." in the parentheses would be better because this is
> not an exhaustive list of examples.
> 

Ok.

> Do you mean that "The IPFIX Mediator must have a specific way to tell
> the Original Exporter IP address to the IPFIX Collector."?
> 
Yes. It's lack of word. I will improve it, as follows.

"The IPFIX Mediator must be able to notify the Collector about the
Original Exporter IP address of the Original Exporter."

Regards,
Atsushi KOBAYASHI

---

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Jun 2009 00:11:53 +0200

Kobayashi-san, Gerhard,
> I have received comments from the Juergen and you. It is too few. :-(
Actually we also received some feedback from Motonori Shindo.
I received feedback from 3 co-workers on the previous version (nothing 
was sent on the list).
I've asked them if they could re-read this version as well.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Jun 2009 09:28:32 +0200

Gerhard,

Thanks for your review.
It's true we spent quite some time on the terminology. This is key for 
any other mediation function related drafts that will follow
> implemented at a "separate IPFIX Mediator/Concentrator/...".
The biggest trouble is the distinction between the intermediate IPFIX 
Mediator and the top IPFIX Mediator. See my point below.
> talk about the instantiation of a specific function.
See below.
> the usage of this term in RFC3917. There, a Concentrator is a device,
It's true that concentrator in RFC3917 might be perceived as a specific 
device, even if it's not formally expressed in the RFC. For example, 
there is no Concentrator definition. However I don't think that the 
compliance with RFC 3917 is our highest priority ;-).

> part of an Exporter (Original Exporter), Collector, or Mediator.
This is where we're going, if you look at figure B of 
http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02

            IPFIX (Flow Records / Packet Reports)
                              ^
                            ^ |
   +------------------------|-|---------------------+
   | IPFIX Mediator         | |                     |
   |                        | |                     |
   |  .---------------------|-+-------------------. |
   | .----------------------+--------------------.| |
   | |          Exporting Process(es)            |' |
   | '----------------------^--------------------'  |
   |                        | |                     |
   |  .---------------------|-+-------------------. |
   | .----------------------+--------------------.| |
   | |    Intermediate Process(es) (optional)    |' |
   | '----------------------^--------------------'  |
   |                        | |                     |
   |  .---------------------|-+-------------------. |
   | .----------------------+--------------------.| |
   | |          Collecting Process(es)           |' |
   | '----------------------^--------------------'  |
   +------------------------|-|---------------------+
                            |
            IPFIX (Flow Records / Packet Reports)

So the intermediate process hosts one of several functions defined below or a combination of them, in any sequence or in any set. <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-10>
       5.3.1 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.1>.  Selection Function . . . . . . . . . . . . . . . . . . 10 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-10>
       5.3.2 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.2>.  Aggregation Function . . . . . . . . . . . . . . . . . 12 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-12>
       5.3.3 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.3>.  Correlation Function . . . . . . . . . . . . . . . . . 13 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-13>
       5.3.4 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.4>.  Modification Function  . . . . . . . . . . . . . . . . 14 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-14>
... to define the IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor, etc...

The question is: should describe the processes in the problem statement 
draft? We've been going back and forth. I think it makes more sense in 
the framework draft. This would be in line between the RFC3917 and the 
IPFIX architecture RFC5470.

Coming back to your questions:

This is what we showed in the figures B and C of the framework draft

I think it will with the framework draft.

Does it make sense?

Regards, Benoit.

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 17 Jun 2009 10:01:03 +0200

Benoit,

I agree, Intermediate Processes do not have to be introduced in the
problem statement.

>> = specific types of IPFIX Mediation

=> specific type of IPFIX Mediator (i.e., this is a device, not a function)

This does not yet solve the complicated language w/r to
separate/original exporter, but is inline with RFC3917.

>> = devices that implements IPFIX Mediation

I think this is a good plan.

Any objections from your side?

Regards,
Gerhard

---

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Jun 2009 10:06:59 +0200

Hi Gerhard and Kobayashi-san,

One more email about the terminology as they were more terminology
specific comments in the latter part of Gerhard's email. Sorry for the
potential confusion
>> Records and IPFIX Messages."
Actually, I have a problem with this proposal, i.e. adding
"transmission" in the IPFIX Mediation definition.
It doesn't fit with the following model (coming from the framework draft):

   +---------------------------+    +---------------------------+
   | Collector {l}             |    | Collector {k}             |
   |[*Application(s)]          |    |[*Application(s)]          |
   |[Collecting Process(es)]   |....|[Collecting Process(es)]   |
   +---------------------------+    +---------------------------+
                    ^    ^              ^  ^
                    |    |              |  |
                    |    +------....----+  |
                    |    |                 |
             IPFIX (Flow Records / Packet Reports)
                    |    |                 |
   +----------------+----+-----+    +-------+-------------------+
   |IPFIX Mediator {j}         |    |IPFIX Mediator {n}         |
   |[*Applications(s)]         |    |[*Applications(s)]         |
   |[Exporting Process(es)]    |    |[Exporting Process(es)]    |
   |[Intermediate Process(es)] |....|[Intermediate Process(es)] |
   |[Collecting Process(es)]   |    |[Collecting Process(es)]   |
   +---------------------------+    +---------------------------+
                    ^    ^               ^
                    |    |               |
                    |    +------....-----+
                    |                    |
             IPFIX (Flow Records / Packet Reports)
                    |                    |
   +----------------+----------+    +----+----------------------+
   |IPFIX Original Exporter {i}|    |IPFIX Original Exporter {m}|
   |[Exporting Process(es)]    |    |[Exporting Process(es)]    |
   |[Metering Process(es)]     |....|[Metering Process(es)]     |
   |[Observation Point(s)]     |    |[Observation Point(s)]     |
   +---------------------------+    +---------------------------+
               ^ ^                        ^ ^
               | |                        | |
            Packets coming to Observation Points

Where we make a clear distinction between the Intermediate Process and
the Exporting Process
The question is: can we have a Intermediate Process that is a Mediation
Function, for example a IPFIX Concentrator, without exporting?
So a Mediation Function does not contain the export.

Double checking the terminology, I realize that there is a mistake:
OLD:

   IPFIX Concentrator

NEW:
   IPFIX Concentrator

      An IPFIX Concentrator is a type of IPFIX Mediation that receives
      Flow Records/Packet Reports, correlates them, aggregates them, or
      modifies them _into new_ Data Records.

>> s/Flow Records\/Packet Reports/Data Records
Then how do you stress that the the input can come from both IPFIX and
PSAMP?

Regards, Benoit.

---

From: Brian Trammell <[email-masked]>
Date: Wed, 17 Jun 2009 11:16:30 +0200

'morning Gerhard, Benoit, all,

I'm still in the middle of my review (there's a much larger message in  
my drafts folder, which I'm changing as this discussion develops) but  
wanted to jump in on this one quickly, inline below...

> separate/original exporter, but is inline with RFC3917.

It also doesn't fix a problem in the Implementation Analysis  
subsections, that suggest the solutions to problems by applying  
various IPFIX Mediator devices. The suggestion here seems to be that  
it is the _devices_ that are important (use a concentrator, use a  
proxy), not the _functions_. This seems wrong, _especially_ at the  
level at which the problem statement should be. It's the functions  
that are important here. HOW to execute them is a detail for the  
framework and drafts below it.

(e.g., the early binding to devices seems to imply that if I want to,  
say, accept both V9 and IPFIX data and forward summary aggregation  
data to a downstream collector, I need to rack three boxes at the  
mediation point according to the problem statement. This seems...  
inappropriately detailed, and incorrect.)

This implies we should also step back and re-examine the boundary  
between the problem statement and framework, and move the appropriate  
terminology and explanation to the appropriate place.

> I think this is a good plan.

As do I, subject to the consideration above. :)

More below, as well...

>> So the intermediate process hosts one of several functions defined  
>> below or a combination of them, in any sequence or in any set. <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-10 
>> >
>>       5.3.1 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.1 
>> >.  Selection Function . . . . . . . . . . . . . . . . . . 10 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-10 
>> >
>>       5.3.2 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.2 
>> >.  Aggregation Function . . . . . . . . . . . . . . . . . 12 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-12 
>> >
>>       5.3.3 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.3 
>> >.  Correlation Function . . . . . . . . . . . . . . . . . 13 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-13 
>> >
>>       5.3.4 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.4 
>> >.  Modification Function  . . . . . . . . . . . . . . . . 14 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-14 
>> >

I would tend to think they go in the framework draft, as well; but  
then the problem statement should really be limited to talking about  
the _types of functions_ (without Capital Letter Terminology) that are  
required to meet the challenges posed by each specific situation. But  
then, any discussion of devices should be generalized, and moved to  
the Framework as well.

>> I think it will with the framework draft.

Yes. Subject to either of the following arrangements:

1. there is only one type of Intermediate Process, which can host any  
number of Mediation Functions (this makes the most sense from the  
implementation point of view), or

2. there exists a type of Intermediate Process for each basic function  
(an Intermediate Aggregation Process, an Intermediate Selection  
Process, and so on; this makes the most sense from a formalization  
point of view)...

---

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Jun 2009 11:36:53 +0200

Gerhard,
> Any objections from your side?
During the review of the draft version 2 , I went through the full list 
of ...

  5.  Mediation Applicability Examples . . . . . . . . . . . . . . . 12
     5.1.  Adjusting Flow Granularity . . . . . . . . . . . . . . . . 12
     5.2.  Hierarchical Collecting Infrastructure . . . . . . . . . . 12
     5.3.  Correlation for Data Records . . . . . . . . . . . . . . . 13
     5.4.  Time Composition . . . . . . . . . . . . . . . . . . . . . 13
     5.5.  Spatial Composition  . . . . . . . . . . . . . . . . . . . 14
     5.6.  Data Record Anonymization  . . . . . . . . . . . . . . . . 15
     5.7.  Data Retention . . . . . . . . . . . . . . . . . . . . . . 15
     5.8.  IPFIX Export from a Branch Office  . . . . . . . . . . . . 16
     5.9.  Distributing Data Records  . . . . . . . . . . . . . . . . 17
     5.10. Flow-based Sampling and Selection  . . . . . . . . . . . . 18
     5.11. Interoperability between Legacy Protocols and IPFIX  . . . 19

... trying to see if we have a good mediation terminology for each case.
Now, here is the question. All the examples should be categorized by a 
mediation function or a mediation device?

 "device" could potentially work, because, in a requirement draft, we 
don't care (yet) about the framework.
Now, if you say:

   IPFIX Proxy

What if I have a mediator that is composed of both the IPFIX Proxy and 
Concentrator functions? How do you call that beast?
Same question if a IPFIX Device such as a router is also an IPFIX 
Masquerading Proxy: is it first a IPFIX Device, or a IPFIX Masquerading 
Proxy?

I think that using "device" is more restricting than a function when we 
think about the framework, because we don't know in advance where the 
function(s) will be applied: in a router, in connection with other 
functions, etc... Using "device" implies an implicit assumption that, 
when using a IPFIX Proxy, IPFIX Concentrator, etc. we have different 
independent boxes.
So, isn't it better to say:

   IPFIX Mediator

      An IPFIX Mediator is an _IPFIX Device_ that implements one or more
      IPFIX Mediation capabilities.  Examples are devices such as
      routers, switches, network management systems (NMS), etc.

Where:

   IPFIX Device

      An IPFIX Device hosts at least one Exporting Process.  It may host
      further Exporting Processes and arbitrary numbers of Observation
      Points and Metering Processes.

So  IPFIX Mediator = devices that implements one or more functions 
called IPFIX Mediation.

Note that I understand your point: "a IPFIX Mediator containing a IPFIX 
Proxy (function)" doesn't sound intuitive in a sentence...

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Jun 2009 11:46:54 +0200

Hi Brian,
> inappropriately detailed, and incorrect.)
Exactly, this is the topic of my previous email.
>>>> Find below my comments for 
>>>> draft-ietf-ipfix-mediators-problem-statement-03
>>>>
>>> below or a combination of them, in any sequence or in any set. 
>>> <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-10> 
>>>
>>>       5.3.1 
>>> <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.1>.  
>>> Selection Function . . . . . . . . . . . . . . . . . . 10 
>>> <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-10> 
>>>
>>>       5.3.2 
>>> <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.2>.  
>>> Aggregation Function . . . . . . . . . . . . . . . . . 12 
>>> <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-12> 
>>>
>>>       5.3.3 
>>> <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.3>.  
>>> Correlation Function . . . . . . . . . . . . . . . . . 13 
>>> <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-13> 
>>>
>>>       5.3.4 
>>> <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.4>.  
>>> Modification Function  . . . . . . . . . . . . . . . . 14 
>>> <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-14> 
>>>
We could go either way, but I guess that the future drafts specifying 
specific mediation functions would prefer the latter.

Regards, Benoit.

---

From: Brian Trammell <[email-masked]>
Date: Wed, 17 Jun 2009 11:48:46 +0200

hi Benoit, all,

(my previous message could have been, in other words, "everything  
Benoit is about to say..." :) )

short replies inline...

On Jun 17, 2009, at 11:36 AM, Benoit Claise wrote:

> During the review of the draft version 2 , I went through the full  
> list of ...
>      5.1.  Adjusting Flow  
> Granularity . . . . . . . . . . . . . . . . 12
>      5.4.  Time  
> Composition . . . . . . . . . . . . . . . . . . . . . 13
>      5.5.  Spatial  
> Composition  . . . . . . . . . . . . . . . . . . . 14
>      5.6.  Data Record  
> Anonymization  . . . . . . . . . . . . . . . . 15
>      5.7.  Data  
> Retention . . . . . . . . . . . . . . . . . . . . . . 15
>      5.9.  Distributing Data  
> Records  . . . . . . . . . . . . . . . . 17
> Now, here is the question. All the examples should be categorized by  
> a mediation function or a mediation device?

Function. :)

>  "device" could potentially work, because, in a requirement draft,  
> we don't care (yet) about the framework.
> Now, if you say:
>    IPFIX Proxy
>
> What if I have a mediator that is composed of both the IPFIX Proxy  
> and Concentrator functions? How do you call that beast?
> Masquerading Proxy: is it first a IPFIX Device, or a IPFIX  
> Masquerading Proxy?
>
> I think that using "device" is more restricting than a function when  
> we think about the framework, because we don't know in advance where  
> the function(s) will be applied: in a router, in connection with  
> other functions, etc... Using "device" implies an implicit  
> assumption that, when using a IPFIX Proxy, IPFIX Concentrator, etc.  
> we have different independent boxes.

Exactly. And that's exactly the level at which we should be addressing  
this here, in the problem statement.

> Note that I understand your point: "a IPFIX Mediator containing a  
> IPFIX Proxy (function)" doesn't sound intuitive in a sentence...

Why are we even talking about explicit IPFIX Mediator device  
subclasses here (beyond the fact that we want to point out that  
mediation is an expansion of the Concentrator defined in 3917)? Can't  
we just handle this in a "history" or "motivation" subsection of the  
introduction? "Note that Mediation was considered by... [RFC3917]..."  
or the like. If we want to introduce that terminology for real, let's  
put it in the Framework. But I'm still skeptical of restricting the  
framework to specific types of devices (or, even, specific types of  
functions) even at the Framework level? Or do we know that we are  
today smart enough to classify completely every possible thing you can  
do to a stream of IPFIX records?

(If I keep this up I'll have covered my whole review just in replies  
to this thread. ;) )

Cheers,

Brian

---

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Jun 2009 12:11:46 +0200

Brian,
> or the like. 
This was our intend behind the sentence:

Should we change it?
> If we want to introduce that terminology for real, let's put it in the 
> Framework. 
Since
    - the terminology must answer all application examples in the 
problem statement
    - the terminology is framework dependent
we must find the answer now: postponing the discussion won't help.
Once we have an agreement, why not put in both drafts
> But I'm still skeptical of restricting the framework to specific types 
> of devices (or, even, specific types of functions) even at the 
> Framework level? 
We're not...
We have the IPFIX Mediation a generic function, and some more specific 
functions derived from it. And future drafts can have their own 
function. For example, a time-based, flow-based, packet-size dependent 
new function.

Actually, re-reading the definition, you're fully right: we are 
restricting the scope of the Mediation Function

OLD:

NEW:

      IPFIX Mediation is a generic function that covers the manipulation
      of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX
      Messages, or their transmission.  _Here is a series of IPFIX 
      Mediation examples:_

Regards, Benoit.
> Or do we know that we are today smart enough to classify completely 
> every possible thing you can do to a stream of IPFIX records?
>

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 17 Jun 2009 14:44:39 +0200

Benoit,

> "transmission" in the IPFIX Mediation definition.

Well, "transmission" was in the draft. It is not my wording.

"transmission" relates to the translation of Netflow into IPFIX etc.
Do to this, I assume that an Intermediate Process is needed because the
records need to be converted. In fact, the function can be quite complex.

I'm open to better text covering such translations. Even "manipulation
of Data Records" (in capital letters) is not precise because if we
import from Netflow. Data Record is an IPFIX term.

So, maybe just "manipulation and conversion of records"?

> It doesn't fit with the following model (coming from the framework draft):

Data Record covers all of them: Flow Records, Packet Reports, Data
Records associated to Option Templates. This is what is meant here, right?

Gerhard

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 17 Jun 2009 15:00:21 +0200

Brian, Benoit,

>> framework and drafts below it.

I agree.

One question is how to call these "functions" (terminology should fit
into the scheme). IMO, terms like "IPFIX Concentrator", "IPFIX Proxy" do
not fit because they are already used in the context of devices. I would
be satisfied with terms like "Concentrator Function", "Proxy Function" etc.

Brian raised another question (below) whether we need to define specific
terms for these functions in the problem statement. I guess the answer
is no because the functions represent _solutions_ , not _problems_ we
want to describe.

>> As do I, subject to the consideration above. :)

As stated above, "IPFIX Concentrator" etc. do not sound like a
_function_ names to me. Therefore, I do not like the current definitions
of these terms.

[...]

>> then, any discussion of devices should be generalized, and moved to

I like this proposal. It implies that we remove the terms

   IPFIX Proxy
   IPFIX Concentrator
   IPFIX Distributor
   IPFIX Masquerading Proxy

from the terminology section of the problem statement draft.

>> implementation point of view), or

As already pointed out in previous mails, I prefer this approach because
it follows the same concept as in PSAMP.

Gerhard

---

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Jun 2009 15:39:00 +0200

> Well, "transmission" was in the draft. It is not my wording.
Right. Sorry.
The draft version 3 says

   IPFIX Mediation

      IPFIX Mediation is a generic function that covers the manipulation
      of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX
      Messages, or their transmission.

The proposal in this thread is:

"...covers the manipulation of the content _and _transmission of Data
Records and IPFIX Messages."

The difference now is "and". This means that we always "transmit" in the 
mediation
If "transmit" is perceived as "exported", then I have a problem
> So, maybe just "manipulation and conversion of records"?
That makes more sense to me, and would be in line with the framework, 
where the Exporting Process is a different process
> Records associated to Option Templates. This is what is meant here, right?
Sure.

Actually, if we keep "manipulation of IPFIX Flow Records, PSAMP Packet 
Reports, or entire IPFIX Messages" in the IPFIX Mediation first 
sentences, then we don't need to repeat "Flow Records/Packet Reports" 
further down in the examples, and the IPFIX Concentrator, IPFIX 
Masquerading Proxy (since their definitions are derived from IPFIX 
Mediation).

I'm convinced now

Regards, Benoit

---

From: Atsushi Kobayashi <[email-masked]>
Date: Thu, 18 Jun 2009 17:56:45 +0900

Hi Benoit, and Gerhard,

> Records and IPFIX Messages."

Do you mean "the transmission of Data Records _or_ IPFIX Messages" ? 
And we also put the (Options) Template Records.

Finally, next version would say.

"IPFIX Mediation is a function that covers the manipulation of the
content and transmission of Data Records, (Options) Template Records, or
IPFIX Messages. Here is a series of IPFIX Mediation examples:

     *  content mediation that changes Data Records information

         +  aggregating Data Records based on a new set of Flow Key
            fields

I agree.

Regards,
Atsushi

---

---

From: Atsushi Kobayashi <[email-masked]>
Date: Thu, 18 Jun 2009 18:04:21 +0900

Hi Gerhard, and all,

On Wed, 10 Jun 2009 21:39:41 +0900

> > and problems of the abstract.

I would like to add the following paragraph in Introduction.

1.  Introduction

   One advantage of Flow-based measurement results from easily offering
   the traffic monitoring of a huge amount of traffic.  While the usage
   is applied to any networks and to multiple measurement applications,
   network administrators need to optimize the resource of metering
   devices and of multiple measurement applications.  IP traffic growth
   and a wide variety of measurement application make it further
   difficult.  To achieve system optimization, an intermediate device
   can generally be applied to the system platform.

   While the IPFIX requirements defined in [RFC3917] mention an
   intermediate device, such as an IPFIX Proxy or an IPFIX Concentrator,
   there are no documents defining the function called IPFIX Mediation.

Regards,
Atsushi

---

---

From: Brian Trammell <[email-masked]>
Date: Thu, 18 Jun 2009 11:12:46 +0200

>   there are no documents defining the function called IPFIX Mediation.

Consider replacing para two with an elaboration:

The IPFIX requirements defined in [RFC3917] mention examples of
intermediate devices, such as IPFIX Proxies or Concentrators,
there are no documents defining a generalized concept for such
intermediate devices. This document addresses that issue by defining
IPFIX Mediation, a generalized intermediate device concept for IPFIX,
and examining in detail the motivations behind its application.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 18 Jun 2009 11:15:35 +0200

>         +  aggregating Data Records based on a new set of Flow Key

If we _must_. I actually prefer to keep examples out of terminology  
(it still looks like it is intended as a covering set) and to define  
_functions_. You have the rest of the document (and indeed, do use it)  
to talk about the examples.

Again, where we do speak specifically, I think we want to talk  
explicitly in terms of defined intermediate processes (e.g.,  
Intermediate Aggregation Process, Intermediate Selection Process, and  
so on), and not try to wedge a covering set of mediation functions  
into a definition "IPFIX Mediation" that isn't really used anywhere  
(i.e., the _document_ talks about IPFIX Mediation, but all of the  
terms to which specifications can be meaningfully applied -- devices,  
processes functions -- are at a lower level...)

---

From: Nishida Haruhiko <[email-masked]>
Date: Thu, 18 Jun 2009 19:18:01 +0900

Brian,

I love your para two. The original (problem-statement-03) 

"there are no documents defining the function called IPFIX Mediation"

is true, but not too make sense. 

-- Haru Nishida, NTT

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 19 Jun 2009 10:27:42 +0200

Hi Atsushi,

>          +  aggregating Data Records based on a new set of Flow Key

Hm, no, see below.

>> where the Exporting Process is a different process

Hence, the current proposal is as follows:

 IPFIX Mediation
     IPFIX Mediation is a generic function that covers the manipulation
     and conversion of records.

"record" can be anything, e.g. Netflow records, PSAMP Packet Reports,
IPFIX Data Records,...
However, Mediation does not handle messages.

This is the figure I have in mind:

IPFIX messages--> CP --records--> IP --records--> EP --IPFIX messages-->

There are no messages entering the IP. Messages occur only at the input
of the CP and at the output of the EP.

Similarly, if IP is located at the Original Exporter:

MP --records--> IP --records--> EP --IPFIX messages-->

Gerhard

---

From: Benoit Claise <[email-masked]>
Date: Fri, 19 Jun 2009 14:07:14 +0200

> to talk about the examples.
This makes sense.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 19 Jun 2009 14:14:19 +0200

Gerhard,
> However, Mediation does not handle messages.
Agreed on the principles.
I would like to introduce somewhere in the terminology that we speak 
primarily about IPFIX Data Records and PSAMP Packet Reports
Do you agree with the proposal?

   IPFIX Mediation

      IPFIX Mediation is a generic function that covers the manipulation
      and conversion of Data Records, such as IPFIX Flow Records and PSAMP Packet Reports.

Justification, the Data Record definition from RFC5101 seems perfect for what we want to express. 

Regards, Benoit.

---

From: Brian Trammell <[email-masked]>
Date: Fri, 19 Jun 2009 14:19:16 +0200

hi, Benoit,

Yes.

s/record/Data Record/g in my previous rewrite of the terminology  
section.

Regards,

Brian

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 19 Jun 2009 22:20:00 +0200

Benoit,

> Justification, the Data Record definition from RFC5101 seems perfect for what we want to express. 

Ok with me. Yet, it should be clear that Data Record is not restricted
to IPFIX Data Records but also covers Netflow records etc.
Therefore, I'm not sure if capital letters are correct.

Gerhard