Subject: [IPFIX] Review: draft-kobayashi-ipfix-mediator-model-00

From: Paul Aitken <[email-masked]>
Date: Wed, 25 Jul 2007 23:39:11 +0100

Kobayashi-san,

Please see my comments inline.

> IPFIX Working Group                                         A. Kobayashi
> Internet-Draft                                              K. Ishibashi
> Intended status: Informational                                 T. Kondoh
> Expires: December 25, 2007                                   NTT PF Lab.
>                                                             D. Matsubara
>                                                                  Hitachi
>                                                            June 23, 2007
> 
> 
>                   Reference Model for IPFIX Mediators
>               draft-kobayashi-ipfix-mediator-model-00.txt
> 
> Status of this Memo
> 
>    By submitting this Internet-Draft, each author represents that any
>    applicable patent or other IPR claims of which he or she is aware
>    have been or will be disclosed, and any of which he or she becomes
>    aware will be disclosed, in accordance with Section 6 of BCP 79.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt.
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
> 
>    This Internet-Draft will expire on December 25, 2007.
> 
> Copyright Notice
> 
>    Copyright (C) The IETF Trust (2007).
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007               [Page 1]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
> Abstract
> 
>    An IPFIX Mediator is an intermediate node between IPFIX devices and

"devices" -> "Exporting Processes"

>    traffic collectors.  This node acts as an IPFIX proxy, IPFIX

"traffic collectors" -> "IPFIX Collecting Processes".

"This node" -> "A mediator"

>    firewall, and IPFIX concentrator.  An IPFIX Mediator mediates the
>    IPFIX protocol using several functions.  That enables the traffic
>    monitoring system to become a high-capacity system and accommodate a
>    variety of traffic monitoring methods.  This document describes each
>    function that is provided by IPFIX Mediators and the method of
>    handling the Flow Records of each function.  In addition, this
>    describes the model of the solution scenario using IPFIX Mediator.

It's unclear what this last line means.

> 
> 
> Table of Contents
> 
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
>    3.  Internal Components Model  . . . . . . . . . . . . . . . . . .  8
>      3.1.  Collecting Process . . . . . . . . . . . . . . . . . . . .  8
>      3.2.  Metering Process . . . . . . . . . . . . . . . . . . . . .  9
>        3.2.1.  Selection Process  . . . . . . . . . . . . . . . . . .  9
>        3.2.2.  Aggregation Process  . . . . . . . . . . . . . . . . .  9
>        3.2.3.  Modification Process . . . . . . . . . . . . . . . . . 10
>      3.3.  Exporting Process  . . . . . . . . . . . . . . . . . . . . 12
>      3.4.  Storing Process  . . . . . . . . . . . . . . . . . . . . . 12
>    4.  IPFIX Protocol Considerations  . . . . . . . . . . . . . . . . 14
>      4.1.  Export Time Issue  . . . . . . . . . . . . . . . . . . . . 14
>      4.2.  Observation Domain ID Management . . . . . . . . . . . . . 14
>      4.3.  Template Management  . . . . . . . . . . . . . . . . . . . 14
>      4.4.  Transport Session Management . . . . . . . . . . . . . . . 15
>      4.5.  Option Template Management . . . . . . . . . . . . . . . . 15
>      4.6.  Reporting of Exporter Information  . . . . . . . . . . . . 15
>    5.  Solution Scenarios with IPFIX Mediators  . . . . . . . . . . . 16
>      5.1.  Flexible Aggregation . . . . . . . . . . . . . . . . . . . 16
>      5.2.  Distributed Aggregation  . . . . . . . . . . . . . . . . . 16
>      5.3.  Duplication of Flow Records  . . . . . . . . . . . . . . . 17
>      5.4.  Distribution of Flow Records . . . . . . . . . . . . . . . 18
>      5.5.  Extraction of Suspicious Flow  . . . . . . . . . . . . . . 19
>    6.  Mediator Option Template Presentation  . . . . . . . . . . . . 20
>      6.1.  Exporter Information Option Template . . . . . . . . . . . 20
>      6.2.  Usage of Scope Field . . . . . . . . . . . . . . . . . . . 22
>    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
>    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
>    9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
>      9.1.  Normative References . . . . . . . . . . . . . . . . . . . 26
>      9.2.  Informative References . . . . . . . . . . . . . . . . . . 26
>    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
>    Intellectual Property and Copyright Statements . . . . . . . . . . 28
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007               [Page 2]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
> 1.  Introduction
> 
>    Several problems regarding traffic monitoring have occurred in
>    several networks, as follows.

Can you cite some references for this?

> 
>    o  Scalability of collector on large-scale networks
> 
>       As the sizes of networks become larger, the number of Flow Records
>       becomes greater.  Large numbers of Flow Records have been
>       burdening management networks and the collecting process.
>       Maintaining scalability is difficult as a particular network
>       grows.  Generally, network operations need to monitor overall
>       wide-scale traffic behavior and investigate detailed traffic
>       information when traffic incidents happen.  Meeting these
>       requirements seems to be difficult for a single collector node
>       because of large numbers of Flow Records.
> 
>    o  Handling multifaceted network environment
> 
>       On the other hand, networks such as IPv4, IPv6, and VPN on MPLS
>       have recently become more multifaceted.  These sorts of Flow

What do you mean by "multifaceted"?

>       Records need to be analyzed separately from a different
>       perspective.  However, handling them separately without improving
>       the capability of the Collector is difficult.
> 
>    o  Exchanging traffic information between different networks
> 
>       Traffic information is considered to be necessary for ISP network
>       providers as well as each customer.  To that end, the network
>       provider needs to export specified Flow Records while avoiding
>       privacy violations.  In addition, exchanging traffic information
>       between the associated networks could be necessary when traffic
>       incidents happen.  In that case, the Flow Records should be
>       checked according to the service provider's policy before
>       exporting.  Therefore, Flow Records exported from Exporter
>       directly without modification can not be fed each customer or

"can not be fed *to* each customer"

>       associated network operators without modification.
> 
>    IPFIX Mediators enable us to overcome these problems by preprocessing
>    Flow Records.  By defining IPFIX Mediators, we can take increasing
>    advantage of an extensive template format, and handle Flow Records in
>    accordance with our preference.  This document describes some
>    solutions using IPFIX Mediators that solve these problems and
>    components that are needed in the internal process.
> 
>    The IPFIX Mediator, which is located between one or more Exporting
>    Processes and one or more Collecting Processes, has a main function
>    for handling Flow Records.  That function stores original Flow
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007               [Page 3]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
>    Records and mediates them.  In addition, renewed Flow Records are

It's worth defining what mediation is.

Also, what are "renewed Flow Records"?

>    generated and distributed to an appropriate Collector or traffic
>    analyzer in accordance with flow content.

Must the mediator understand the content? eg, what about Enterprise 
Specific elements?

>    The internal model of a Mediator is composed of Collecting Processes,
>    Metering Processes, and Exporting Processes.  IPFIX Mediator acts as
>    a Collector by receiving Flow Records, and it acts as an Exporter by
>    sending Flow Records.  This dual-role architecture enables cascading
>    Mediators and building a combination of several solutions.
> 
>    This document describes a model of a solution scenario by using IPFIX
>    Mediator and its key component.
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007               [Page 4]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
> 2.  Terminology
> 
>    The definitions of basic IPFIX and PSAMP terms are identical with
>    those in [I-D.ietf-psamp-framework], [RFC3917],
>    [I-D.ietf-ipfix-protocol], [I-D.ietf-ipfix-info], and
>    [I-D.ietf-ipfix-architecture].  Other than the above terminology, the
>    following terminology related to IPFIX Mediator is used in this
>    document.  Therefore, the terms defined in the IPFIX terminology are
>    capitalized in this document.
> 
>    IPFIX Mediator
> 
>       An IPFIX Mediator hosts at least one pair of Exporting Process and
>       Collecting Process.  An IPFIX Mediator may have the Metering

"at least one Exporting Process and one Collecting Process".

>       Process and Storing Process as optional.  An IPFIX Proxy, an IPFIX

"may optionally have Metering Processes and Storing Processes".

>       Firewall and an IPFIX concentrator are one node of IPFIX
>       Mediators.

This last line is unclear.

> 
>    Original Exporter
> 
>       An Original Exporter hosts Observation Points where IP packets can
>       be observed.
> 
>    IPFIX Proxy
> 
>       An IPFIX Proxy acts as a proxy for Original Exporter, which hosts

"Exporters"

>       Observation Points.  An IPFIX Proxy may receive Flow Records from
>       one or multiple Exporting Processes, and send them to one or
>       multiple Collecting Processes.  An IPFIX Proxy does not send the
>       information about an Original Exporter to the Collector to act as
>       an Original Exporter.

This last line is unclear.

> 
>    IPFIX Firewall
> 
>       An IPFIX Firewall exports the Flow Records to a different network
>       domain at the edge of the self-network domain.  From the
>       Collector's point of view, an IPFIX Firewall acts as an Original
>       Exporter, just like an IPFIX Proxy.  In addition, an IPFIX
>       Firewall reviews whether received Flow Records are passed forward
>       to the Collector to hide the network topology or privacy
>       information.

Does it block records, or modify them? eg, does it anonymise them?

> 
>    Metering Process
> 
>       The Metering Process in IPFIX Mediators can be considered the
>       partial Metering Process separated from the Metering Process in
>       the Original Exporter.  The Metering Process in IPFIX Mediators
>       consists of a set of subprocesses that includes the Selection
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007               [Page 5]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
>       Process, the Aggregation Process and the Modification Process.
>       The Metering Process generates the final Flow Records that should
>       be exported.
> 
>    Selection Process
> 
>       The Selection Process in an IPFIX Mediator is similar to that of
>       PSAMP Devices, which is described in [I-D.ietf-psamp-framework].
>       However, the Selection Process in an IPFIX Mediator differs from
>       the following functions.  The Selection Process in PSAMP Devices
>       has two types of selection functions: Filtering and Sampling.  In
>       addition, the filtering function has two types of filtering
>       methods: field-match filtering and hash-based selection.  The
>       Selection Process in an IPFIX Mediator has only the field-match
>       filtering functions.  This filtering function selects Flow Records
>       based on Flow Record content.  The Selection Process is one of the
>       subprocesses in the Metering Process.
> 
>    Aggregation Process
> 
>       The Aggregation Process creates aggregated Flow Records from
>       inputted Flow Records, in accordance with aggregation rules that
>       are described in [I-D.dressler-ipfix-aggregation].  The
>       Aggregation Process is one of the subprocesses in the Metering
>       Process.
> 
>    Modification Process
> 
>       The Modification Process carries out the addition, deletion, and
>       modification of the Information Elements included in inputted Flow
>       Records.  The Modification Process adds Information Elements like
>       derived packet properties that canot be extracted in the Original
>       Exporter.  Information Elements related to derived packet
>       properties are described in [I-D.ietf-ipfix-info].  In addition,
>       the Modification Process modifies the values of the specific
>       Information Element.  For example, the modification of values is

"the values of specific Information Elements"

>       like anonymizing some Information Elements to avoid violating
>       privacy.  The Modification Process deletes some Information
>       Elements included in inputted Flow Records.  The Modification
>       Process is one of the subprocesses in the Metering Process.

- and presumably this is a key part of a firewall?

> 
>    Storing Process
> 
>       The Storing Process selects specified Information Elements
>       according to the storing rules, and then stores inputted Flow
>       Records in a storage system such as a database or flat-file
>       system.  Information Elements are specified in storing rules.  In
>       addition, the Observation Domain ID and Export Time in the header
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007               [Page 6]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
>       of IPFIX messages are specified in the storing rules.

How does information get *out* of the Storing Process?

> 
>    Distribute Function
> 
>       The Distribute Function distributes final Flow Records based on
>       the Flow content.  The final Flow Records are handled by the
>       Exporting Process to export them to Collector.  Each classified
>       Flow Record is exported to each Collector.

To all collectors, or to a subset?

> 
>    Observation Domain ID
> 
>       An IPFIX Mediator doesn't host the Observation Point and
>       Observation Domain.  Though, the Observation Domain ID in IPFIX
>       header sent by IPFIX Mediator also indicates the largest set of
>       Observation Points in the Original Exporter, but this value does
>       not indicate the physical entity of the Original Exporter.  If
>       inputted Flow Records are aggregated in the Metering Process, the
>       Observation Domain ID value in IPFIX header SHOULD be 0.

I think only if the mediator is spoofing the original source exorter. 
Arguably a whole new set of Observation Domain values applies on the 
mediation device.

>    Transport Session Information
> 
>       In SCTP, the Transport Session Information is the SCTP
>       association.  In TCP and UDP, the Transport Session Information
>       corresponds to a 5 tuple {exporter IP address, collector IP
>       address, exporter transport port, collector transport port,
>       transport protocol}.  In IPFIX Mediator, the Collecting Process
>       manages this information.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007               [Page 7]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
> 3.  Internal Components Model
> 
>    The following figure indicates four components (Collecting Process,
>    Metering Process, Exporting Process, and Storing Process) within the
>    IPFIX Mediator that are referred to in [RFC3917].  The Metering
>    Process can have one or multiple subprocesses.  These subprocesses
>    are the Selection Process, Aggregation Process, and Modification
>    Process that can be connected to each other in any sequence defined
>    by the user.  The Metering Process and Storing Process are options.
> 
> 
>      +--------------------------------------------------------------+
>      |                        IPFIX Mediator                        |
>      | .----------.                                     .---------. |
>      | |          |  .-------------------------------.  |         | |
>      | |Collecting|  |        Metering Process       |  |Exporting| |
>      | |Process   |  |.-------.  .-------.  .-------.|  |Process  | |
>      | |          |-->|sub    |->|sub    |->|sub    |-->|         | |
>    IPFIX          |  ||process|  |process|  |process||  |         |IPFIX
>    --> |          |  ||#1     |  |#2     |  |#3     ||  |         |-->
>      | |          |  |'-------'  '-------'  '-------'|  |         | |
>      | |          |  '-------------------------------'  |         | |
>      | |          |------------------------------------>|         | |
>      | |          |  .-------.                          |         | |
>      | |          |->|Storing|                          |         | |
>      | |          |  |Process|                          |         | |
>      | |          |  '-------'                          |         | |
>      | '----------'                                     '---------' |
>      +--------------------------------------------------------------+

I think any of the metering sub-processes should be able to send data to 
the storing process. Also, the Exporting process may send data there too 
(consider Brian's file draft). Finally, there should be a route *out* of 
the storing process - either to the outside, and/or to the Metering 
Process, and/or to the Exporting Process.

>    Figure A: Key components within IPFIX Mediator.
> 
>    Each process is associated with a common identifier in the IPFIX
>    Mediator.  This method is similar to PSAMP associations in
>    [I-D.ietf-psamp-sample-tech].
> 
> 3.1.  Collecting Process
> 
>    This process receives Flow Records from the previous Exporter.  The
>    instance of this process is created according to the IPFIX session.
>    This process has functions that are described in
>    [I-D.ietf-ipfix-protocol].  The Collecting Process also forwards
>    received Flow Records with IPFIX header information and Transport
>    Session Information to multiple Metering Processes or Storing
>    Processes.  In other words, Flow Records can be duplicated by
>    forwarding several Metering Processes.  In addition, the Collecting

Or Exporting Processes.

>    Process can directly forward Flow Records to Exporting Process.
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007               [Page 8]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
> 3.2.  Metering Process
> 
>    This process generates the renewed Flow Records from inputted Flow
>    Records with received IPFIX header information, such as "Export Time"
>    and "Observation Domain ID".  This process hosts the several
>    subprocesses.  The processing order of these functions, which could
>    be located by user definitions, would lead to different renewed Flow
>    Records.
> 
> 3.2.1.  Selection Process
> 
>    This process decides whether each Flow Record passes through to the
>    next process.  Theprocess has a filtering function and selects Flow

Typo, "Theprocess".

>    Records that are matched under given conditions.  Prior to receiving
>    Flow Records, this process has instruction pattern data that are
>    defined by the user, which specifies how the Flow Records are treated
>    by this process.  If the value of some Information Elements in the
>    Flow Record match the instruction pattern, this process selects Flow
>    Records with all fields and forwards these Flow Records to the next
>    process.  For example, this process selects the Flow Records that are
>    included in the specified destination IP address.
> 
> 3.2.2.  Aggregation Process

As a general question, is it valid to aggregate fields which were not 
originally key fields?

> 
>    This process gathers Flow Records within a given time interval and
>    then distinguishes Flow Records that have common properties.  If
>    values of a given key field are the same, that means these Flow
>    Records have common properties.  This process merges Flow Records
>    that have a common property and creates an aggregated Flow Record.
>    Therefore, for example, aggregated Flow Records have an aggregation
>    counter that indicates the number of packets.  These functions are
>    defined in accordance with the IPFIX aggregation rule in
>    [I-D.dressler-ipfix-aggregation].
> 
>    The process has instructions that are user defined prior to receiving
>    Flow Records.  The process indicates the Information Elements that
>    should become aggregated flow keys and other Information Elements
>    that should be kept or discarded.  In addition, these instruction
>    rules include Information Elements that should be added to aggregated
>    Flow Records.  The aggregated Flow Records may need to complement
>    information that is discarded during the aggregation process.  They
>    help the Collector to analyze aggregated Flow Records.  For example,
>    these Information Elements correspond to "averageActiveTime",
>    "synCount", and "flowCount" elements, as follows.
> 
>    o  averageActiveTime
> 
>       This Information Element indicates average time in milliseconds of
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007               [Page 9]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
>       difference between flow start time and end time of each flow
>       included in the aggregated flow.  This Information Element is
>       created from the flow time stamp Information Elements.  There are
>       "flowStartSeconds", "flowEndSeconds", "flowStartMilliSeconds",
>       "flowEndMilliSeconds", "flowStartSysUpTime", and
>       "flowEndSysUpTime".  Moreover, "minimumActiveTime" and
>       "maxmumActiveTime" might be considered in addition to the element.
> 
>    o  synCount
> 
>       This Information Elements the number of Flow Records that have
>       "tcpControlBits" which the SYN bit sets to 1 in an aggregated
>       flow.  Using this element, we can determine the number of SYN
>       packets throughout the network.  Moreover, "ackCount", "finCount",
>       "pshCount", "urgCount", and "rstCount" might be considered in
>       addition to this element.
> 
>    o  flowCount
> 
>       This Information Element is the number of Flow Records included in
>       the aggregated flow.
> 
> 3.2.3.  Modification Process
> 
>    This process modifies the received Flow Records.  This process can
>    add the new Information Elements, delete included Information
>    Elements, or modify the value of included Information Elements, as
>    follows.  If this process modify the original template, it SHOULD
>    revise the received "flowKeyIndicator".
> 
>    Addition of new Information Element
> 
>       This function adds specified Information Elements into the
>       inputted Flow Records.  The values of Information Elements are
>       extracted by searching some database based on the inputted content
>       of Flow Records.  The added Information Elements and used
>       Information Elements are configured according to instructions by
>       the user to obtain the value.  The method to obtain the value from
>       some Information Elements is outside the scope of this document.
> 
>       The IPFIX Mediator instead of the Original Exporter adds a derived
>       packet property parameter, which is useful for the traffic
>       monitoring technique.  Doing that can compensate for the inability
>       of some Exporters to add a derived packet property parameter.
>       Hereby, the Collector does not need to recognize the difference
>       between implementations of routers from several vendors.  For
>       example, the addition of "bgpNextHop{IPv4|IPv6}Address" and
>       "bgpCommunity" Information Elements is useful for making a traffic
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 10]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
>       matrix that covers the whole network domain. "bgpNextHop{IPv4|
>       IPv6}Address" can indicate the egress router of some network
>       domain.  In addition, "bgpCommunity" can indicate the same group
>       of destination or source IP addresses.  This value can be given by
>       looking for the BGP route database based on the destination or
>       source IP address.  In addition, "mplsVpnRouteDistinguisher",
>       which can not be extracted from the core router in MPLS networks,
>       indicates the customer's identification.  We can monitor the
>       traffic behavior per customer by adding
>       "mplsVpnRouteDistinguisher" to the Flow Records.  This value can
>       be given by looking for the BGP route database based on the
>       "mplsTopLabelStackSection" and "mplsTopLabel{IPv4|IPv6}Address".
> 
>    Deletion of Information Element
> 
>       This function deletes specified Information Elements according to
>       the instructions that are configured by the user, which indicate
>       whether an Information Element should be removed.  Hiding network
>       topology information and private information by using this
>       function is possible.
> 
>       In the case of exchanging Flow Records with different network
>       domains or customers, this function can avoid making a
>       vulnerability by deleting unnecessary Information Elements.  By
>       deleting unnecessary Information Elements, this function can hide
>       the network topology and another customer's information.  In
>       particular, "ipNextHopIP{v4|v6}Address", "bgpNextHopIP{v4|
>       v6}Address", and "bgp{Next|Prev}AdjacentAsNumber" correspond to
>       network topology information.  In addition, MPLS-related
>       Information Elements, such as "mplsLabelStackSection", that are
>       useless for customers might be removed in the case of feeding the
>       Flow Records to VPN customers.
> 
>    Modification of the value of Information Element
> 
>       This function modifies the value of specified Information Elements
>       according to instructions configured by the user.
> 
>       For example, this function enables us to overwrite private
>       information with zeros or the maximum value.  In particular, IP
>       address and port number is sensitive private information.  In the
>       case of monitoring traffic trends and traffic engineering, these
>       Information Elements are not essential factors for those purposes.
>       In that case, modification anonymizes the relevant Information
>       Elements to prevent a violation of privacy.  If modification can
>       anonymize some Information Elements, it might need to report which
>       Information Elements are anonymized.  For example,
>       "anonymizationIndicator" indicates which Information Elements have
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 11]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
>       been anonymized as a bitmap, just like the "flowKeyIndicator".
>       The anonymization method is outside the scope of this document.

Why would we not just modify the template and remove these Information 
Elements?

> 
> 3.3.  Exporting Process
> 
>    This process forwards Flow Records to the next Collector.  These
>    processes manage the reporting template and make an IPFIX datagram.
> 
>    In addition, this process has the Distribution Function as an option.
>    If this function is enabled, this process distributes Flow Records
>    based on Flow content and then exports each classified Flow Record to
>    each Collector.
> 
>    The Exporting Process distributes Flow Records on the basis of the
>    peering AS, as shown in the following figure.  Each classified Flow

Peer AS in the incoming data, or on the Exporting side? Is BGP required?

Surely this would/should be user configurable?

>    Record is exported to a dedicated Collector on the basis of the
>    Peering AS.
> 
>      +-------------------------------------------+
>      | IPFIX Mediator               .----------. |
>      |                              |Exporting | |
>      |                              |Process   | |
>      |   .----------.  .---------.  |          | | PeerAS#100
>  Flow -->|Collecting|->|Metering |----->/------------> Collector#A
>  Records |Process   |  |Process  |  |   |      | | PeerAS#200
>      |   '----------'  '---------'  |   /------------> Collector#B
>      |                              |   |      | | PeerAS#300
>      |                              |   /------------> Collector#C
>      |                              |   |      | | PeerAS#400
>      |                              |   /------------> Collector#D
>      |                              |          | |
>      |                              '----------' |
>      +-------------------------------------------+
> 
>  Figure B: Exporting each classified Flow Record to dedicated Collector.
> 
> 3.4.  Storing Process
> 
>    This process selects specified Information Elements using the storing
>    instruction from the inputted Flow Records.  Prior to receiving Flow

What is the "storing instruction" ?

>    Records, this process has instructions that are configured by the
>    user, which indicate whether each field should be stored or
>    discarded.  The field modifier indicates "keep" or "discard", which
>    is similar to the instruction of the aggregation process.  The field
>    modifier specifies how these Information Elements are treated by the
>    process.  This field modifier is applied to Information Elements
>    within Flow Record and IPFIX header, such as "Observation Domain ID"
>    and "Export time".  This header information MAY be used when IPFIX
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 12]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
>    datagrams are made of past Flow Records.
> 
>    When another node retrieves past Flow Records, we can consider

How does it retrieve them?

>    several specifications.  One solution is that another node gets a
>    specified flat file from a Mediator and decodes that flat file by
>    itself.  Other solutions are that another node sends out the query
>    command to the IPFIX Mediator through XML-RPC, SNMP, or NETCONF, and
>    then the IPFIX Mediator exports the specified past Flow Records.
>    This function is outside the scope of this document.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 13]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
> 4.  IPFIX Protocol Considerations
> 
>    This section describes IPFIX protocol considerations with regard to
>    IPFIX Mediator.
> 
> 4.1.  Export Time Issue
> 
>    If the Exporting Process writes the "Export Time" of the IPFIX
>    message when an IPFIX message leaves, an IPFIX Mediator needs to
>    compensate for the delta time Information Elements contained in each

"the" -> "any"

>    Flow Record.  An IPFIX Proxy SHOULD reuse the "Export Time" of

"SHOULD" -> "MUST"

>    received IPFIX messages from the Original Exporter.
> 
> 4.2.  Observation Domain ID Management
> 
>    To comply with the IPFIX protocol the Observation Domain ID value is
>    RECOMMENDED to be assigned uniquely per IPFIX Mediator.  In addition,
>    Observation Domain ID SHOULD be 0 when IPFIX Mediator exports
>    aggregated Flow Records and cannot manage the specific Observation
>    Domain ID of the Original Exporter.  If an IPFIX Proxy relays an
>    IPFIX datagram from a transport session to a transport session, IPFIX
>    Proxy does not need to overwrite the Observation Domain ID with
>    another value.  If an IPFIX Proxy relays an IPFIX datagram from
>    multiple transport sessions to a single ransport session, IPFIX Proxy
>    needs to overwrite the Observation Domain ID.  In that case, IPFIX
>    Proxy assigns the Observation Domain ID based on received Transport
>    Session Information and the original Observation Domain ID.  The
>    renewed Observation Domain ID SHOULD be managed using the received
>    Transport Session Information and original Observation Domain ID.
>    This linkage information is available for overwriting the scope field
>    of the option template.
> 
> 4.3.  Template Management
> 
>    The template ID of a generated template SHOULD be unique on the basis

"Template". Please be sure to capitalise IPFIX terminology!

>    of the Observation Domain ID assigned by an IPFIX Mediator.  The
>    template ID needs to be unique on the basis of IPFIX Mediator when
>    the Observation Domain ID is 0.  If the IPFIX Mediator overwrites the
>    received template ID to relay a received template or modified
>    template, the renewed template ID SHOULD be managed using received
>    Transport Session Information and received Observation Domain ID.
>    This linkage information is available for overwriting scope field of
>    an option template and template handling.  If IPFIX Mediator receives
>    a "template withdraw message", it SHOULD modify this message to
>    indicate relevant templates, and send "template withdraw message".
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 14]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
> 4.4.  Transport Session Management
> 
>    Each session of the Collecting Process and Exporting Process should
>    operate independently.  Even if one session is reset, the status of
>    the other session is kept current.  However, templates for resetting
>    collecting session SHOULD be withdrawn for the exporting session.
> 
> 4.5.  Option Template Management
> 
>    IPFIX Mediator MUST check whether the scope field is applicable, if
>    received Data Records associated Options templates are exported.  If
>    an IPFIX Mediator rewrites the Observation Domain ID or template ID,
>    these values included in scope fields SHOULD be rewritten before
>    exporting.  Instead of exporting the Options Template Records and
>    associated Data Records, Information Elements exported using the
>    Options template Record from the Original Exporter, such as sampling
>    rate or sampling method, could be merged in a Flow Record in an IPFIX
>    Mediator.  In that case, IPFIX Mediator MUST modify the relevant
>    Template Record.  Several sorts of received statistics Options
>    Template Records and associated Data Records could be exported in
>    different ways as other templates.  In IPFIX Proxy, the Data Record
>    associated by statistics Options Template Records can be exported
>    after merging its counter.  In addition, statistics Options Template
>    Records and associated Data Records can be exported by indicating the
>    source of the statistics data as a scope field instead of merging the
>    counter.  This method is described in Section 6.  The user policy
>    determines whether IPFIX Mediator and the above methods should export
>    Option Templates Records and associated Data Records.
> 
> 4.6.  Reporting of Exporter Information
> 
>    Reporting of Exporter Information, such as Exporter IP address, is

Surely that's a loss of privacy?

>    useful to identify the Original Exporter.  There are various methods
>    as follows.  An IPFIX Mediator can directly merge Exporter
>    Information into Flow Records or use Options Templates described in
>    Section 6.  If an IPFIX Mediator received fields related to the
>    Exporter information, IPFIX Mediator SHOULD NOT rewrite its own
>    previous Exporter information.  The IPFIX Mediator can append its own
>    previous Exporter Information instead of rewriting.  In the
>    Collecting Process, the order of the Exporter information means the
>    Original Exporter and the route of IPFIX Mediator.  These methods
>    defined by user policy determine whether IPFIX Mediator should report
>    that information has been exported

Some text seems to be missing here?

> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 15]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
> 5.  Solution Scenarios with IPFIX Mediators
> 
> 5.1.  Flexible Aggregation
> 
>    An IPFIX Mediator can aggregate Flow Records in the same manner as
>    that of IPFIX concentrator and reduce the number of Flow Records
>    received by a traffic collector.
> 
>    The following figure indicates a cascade connection of IPFIX
>    Mediators.  If a Collector measures a traffic matrix to obtain
>    traffic demand, the Collector needs Flow Records of the whole network
>    domain, but does not need detailed Flow Records.  In the first step,
>    a Mediator receives Flow Records from IPFIX Devices and then creates

"a first level Mediator"

>    aggregated low-level Flow Records.  For example, this step is prefix
>    mask aggregation.  Next, the Mediator receives aggregated Flow

"Next, a second level Mediator"

>    Records and aggregates them further.  For example, the second step is
>    the aggregation of the BGP next-hop address and exporter address.
>    After this, the collector receives high-level aggregated Flow Records
>    and then stores them.  This method enables step-by-step aggregation
>    of Flow Records without overloading a single node.
> 
>    .--------.     .--------.
>    |IPFIX   |     |IPFIX   |
>    |router#1|---->|Mediator|---.
>    |        |     |*1      |   |
>    '--------'     '--------'   |    .--------.     .---------.
>                                '--->|IPFIX   |     |Traffic  |
>    .--------.     .--------.   .--->|Mediator|---->|Collector|
>    |IPFIX   |     |IPFIX   |   |    |*2      |     |         |
>    |router#2|---->|Mediator|---'    '--------'     '---------'
>    |        |     |*1      |
>    '--------'     '--------'
> 
>    Figure C: Flexible Aggregation with cascading IPFIX Mediators.
> 
> 5.2.  Distributed Aggregation
> 
>    When the network is used globally, the distances between PoPs become
>    longer, and the maintenance of a dedicated management network is very
>    expensive.  Therefore, the huge number of Flow Records has burdened
>    the management networks of global ISPs.  If we place Mediators at
>    each PoP, the number of Flow Records exported from each PoP can be
>    reduced.  Mediators can minimize the number of Flow Records exported
>    to the Collector.  If the Collector needs detailed information, it
>    can retrieve Flow Records from Mediators that store original Flow
>    Records.
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 16]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
>    A management network of a global ISP is shown in the following
>    figure.  The Mediators are located at each PoP of the network, and
>    they collect Flow Records from routers in each PoP domain.  The
>    Mediator reduces the number of Flow Records by aggregating or
>    filtering, so this system reduces the load of a management network.
> 
>                 POP#Asia
>         .--------.
>       .--------. |      .---------.
>     .--------. | |----->|IPFIX    |
>     |IPFIX   | |------->|Mediator |----.
>     |router  |---'----->|#1       |    |
>     |#1      |-'        '---------'    |
>     '--------'                         |
>                                        |
>                 POP#America            |
>         .--------.                     |
>       .--------. |      .---------.    |     .---------.
>     .--------. | |----->|IPFIX    |    '---->|Traffic  |
>     |IPFIX   | |------->|Mediator |--------->|Collector|
>     |router  |---'----->|#2       |    .---->|         |
>     |#4      |-'        '---------'    |     '---------'
>     '--------'                         |
>                                        |
>                 POP#Europe             |
>         .--------.                     |
>       .--------. |      .---------.    |
>     .--------. | |----->|IPFIX    |    |
>     |IPFIX   | |------->|Mediator |----'
>     |router  |---'----->|#3       |
>     |#7      |-'        '---------'
>     '--------'
> 
>    Figure D: Traffic monitoring architecture in global network.
> 
> 5.3.  Duplication of Flow Records
> 
>    An IPFIX Mediator duplicates Flow Records to achieve redundant
>    storage or utilizes them for several purposes.  The pair of
>    Collecting Process and Metering Processes is similar to the pair of
>    the Observation Point and Metering Process.  The Collecting Process
>    duplicates Flow records by forwarding them to the multi-Metering
>    Process.
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 17]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
>    Several departments in an ISP want to use the same traffic
>    information for each intended purpose.  For example, the network
>    design department measures the traffic matrix to obtain traffic
>    demand, and the customer service division uses traffic information
>    for performing accounting services for each customer while the
>    network operation center uses traffic information for trouble
>    shooting analysis.  That case is shown in the following figure.  An
>    IPFIX Mediator distributes Flow Records to several Collectors that
>    have the appropriate aggregated granularity.  In addition, when a NOC
>    conducts troubleshooting, past Flow Records from Mediators can be
>    retrieved.
> 
>                                          Measurement traffic matrix.
>    .--------.                               .---------.
>    |IPFIX   |                               |Traffic  |
>    |router#1|----.                    .---->|Collector|
>    |        |    |                    |     |#1       |
>    '--------'    |                    |     '---------'
>                  |                    |  Using Accounting info.
>    .--------.    |     .---------.    |     .---------.
>    |IPFIX   |    '---->|IPFIX    |----'     |Traffic  |
>    |router#2|--------->|Mediator |--------->|Collector|
>    |        |    .---->|         |----.     |#2       |
>    '--------'    |     '---------'    |     '---------'
>                  |                    |  Using Trouble shooting.
>    .--------.    |                    |     .---------.
>    |IPFIX   |    |                    |     |Traffic  |
>    |router#1|----'                    '---->|Collector|
>    |        |                               |#3       |
>    '--------'                               '---------'

The bottom left router should be "router#3"

> 
>    Figure E: Duplication of Flow Records for several purposes.
> 
> 5.4.  Distribution of Flow Records
> 
>    An IPFIX Mediator distributes Flow Records based on Flow Record

"MAY distribute"

>    content.  This function enables load balancing of Collector and
>    sorting Flow Records without extra Collector functions.  If the Flow
>    Records are used as accounting information, this solution is useful.

It's unclear to me what this means.

> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 18]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
>    When we disclose traffic information to each customer, security or

"we"? -> The mediator, perhaps?

>    the privacy policy should be considered.  In that case, IPFIX
>    Mediator hides private information about each customer.  For example,
>    Mediator distributes traffic information based on RD (Route
>    Distinguisher), egress IF, peering AS number, or BGP next hop, which
>    identify the customer.  In the following figure, the IPFIX Mediator
>    distributes Flow Records based on RD.  The system securely allows
>    each customer to access only their own records.
> 
>    .--------.                               .---------.
>    |IPFIX   |                               |Traffic  |
>    |router#1|----.                    .---->|Collector|<===> Customer#A
>    |        |    |                    |     |#1       |
>    '--------'    |                    |     '---------'
>                  |                 RD=100:1
>                  |     .---------.    |
>    .--------.    '---->|IPFIX    |----'     .---------.
>    |IPFIX   |          |Mediator | RD=100:2 |Traffic  |
>    |router#2|--------->|         |--------->|Collector|<===> Customer#B
>    |        |          |         |          |#2       |
>    '--------'    .---->|         |----.     '---------'
>                  |     '---------'    |
>                  |                 RD=100:3
>    .--------.    |                    |     .---------.
>    |IPFIX   |    |                    |     |Traffic  |
>    |router#1|----'                    '---->|Collector|<===> Customer#C
>    |        |                               |#3       |
>    '--------'                               '---------'
> 
>    Figure F: Distribution of Flow Records for each customer.
> 
> 5.5.  Extraction of Suspicious Flow
> 
>    An IPFIX Mediator performs filtering based on Flow Record content.
>    If the filter conditions are set depending on the suspicious flow as
>    follows, the Collector receives the specified suspicious flow and
>    detects an anomalous flow by simply monitoring the traffic volume of
>    each suspicious flow.
> 
>    o  TCP Flow Records whose "tcpControlBits" value is set to "null"
> 
>    o  TCP Flow Records whose "tcpControlBits" value is set to the SYN
>       bit only and the packet counter is only 1.

This will always happen for TCP flows of 1 or more packets. It might be 
suspicious if the count was still 1 after some time.

> 
>    o  ICMP Flow Records whose length is too long.
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 19]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
> 6.  Mediator Option Template Presentation
> 
>    This section describes Option Templates that are used by IPFIX
>    Mediators.
> 
> 6.1.  Exporter Information Option Template
> 
>    Each IPFIX Mediator and final destination Collector needs to know the
>    Original Exporter and route of IPFIX Mediators.  Therefore, each
>    IPFIX Mediator informs the next Collector about previous Exporter
>    information, which is the Exporter Information Option Template that
>    specified the Original Exporter and the route of the IPFIX Mediator.
>    The final destination Collector can recognize them by receiving this
>    template.  This template is composed of the following Information
>    Elements.
> 
>    o  exporter{IPv4|IPv6}Address
> 
>    o  collector{IPv4|IPv6}Address
> 
>    o  exporterTransportPort
> 
>    o  collectorTransportPort
> 
>    o  collectorTransportProtocol
> 
>    o  observationDomainId
> 
>    The Observation Domain ID of the Original Exporter or IPFIX Mediator
>    is identified by specifying exporter/collector Information Elements,
>    such as "collector{IPv4|IPv6}Address", "collectorTransportPort",
>    "collectorTransportProtocol", ,"exporter{IPv4|IPv6}Address",
>    "exporterTransportPort", and "observationDomainId".  The set of
>    "observationDomainId" and "templateId" or "observationDomainId" might
>    be used as a scope field.  Not all Information Elements are
>    necessary.  For example, the exporter{IPv4|IPv6}Address is necessary
>    to inform the next Collector the Original Exporter which created Flow
>    Records.  If the IPFIX Mediator receives this template, it SHOULD not
>    overwrite each field.  The IPFIX Mediator appends its own previous
>    Exporter information onto received Data Records specified by the
>    Exporter Option Template and sends that information to the Collector.
>    In this manner, the route is maintained until the final destination
>    Collector.
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 20]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
>    The following example describes the cascade connection of IPFIX
>    Mediators.  Each Mediator informs the next Collector about previous
>    Exporter information.
> 
>           Session#a            Session#b            Session#c
>    Router --------> Mediator#1 --------> Mediator#2 -------->Collector
>    IP:1.1.1.1       IP:2.2.2.2           IP:3.3.3.3
>    SrcPort:10       DstPort:20           DstPort:40
>    ODID:10          SrcPort:30           SrcPort:50
>                     ODID:0               ODID:0
> 
>    Figure G: Cascade connection of IPFIX Mediators.
> 
>    Mediator#1 or Mediator#2 sends a Data Record specified by the
>    Exporter Option Template.  The Data records are shown in Session#b or
>    Session#c, as follows.
> 
>    Session#b Data Record:
>       Field Count = 7
>       Scope Count = 1
>       templateId = XXX
>       exporterIPv4Address = 1.1.1.1
>       collectorIPv4Address = 2.2.2.2
>       collectorTransportProtocol = 16
>       exporterTransportPort = 10
>       collectorTransportPort = 20
>       observationDomainId = 10

Could you use real-world values in the examples here and below?

P.

> 
>    Session#c Data Record:
>       Field Count = 13
>       Scope Count = 1
>       templateId = XXX
>       exporterIPv4Address = 1.1.1.1
>       collectorIPv4Address = 2.2.2.2
>       collectorTransportProtocol = 16
>       exporterTransportPort = 10
>       collectorTransportPort = 20
>       observationDomainId = 10
>       exporterIPv4Address = 2.2.2.2
>       collectorIPv4Address = 3.3.3.3
>       collectorTransportProtocol = 16
>       exporterTransportPort = 30
>       collectorTransportPort = 40
>       observationDomainId = 0
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 21]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
> 6.2.  Usage of Scope Field
> 
>    An IPFIX Mediator needs to send forward a Options Template Records
>    and associated Data Records from the Original Exporter.  However,
>    IPFIX Mediator can not export an original Option Template Records and
>    associated Data Records without modification because changing a
>    session from an Exporting Process to a Collecting Process causes the
>    scope fields to become a useless value.  When an IPFIX Mediator
>    relays the Options Template Records that included Observation Domain
>    ID as a scope field and associated Data Records, an IPFIX Mediator
>    uses the Exporter Information Option Template.  The Options Template
>    Records that were created from an Original Exporter can use the
>    entire fields of the Exporter Information Option template as multiple
>    scope fields.  The Options Template Records that were created from
>    anIPFIX Mediator can uses the some fields of the Exporter Information
>    Option template as multiple scope fields.  An IPFIX Mediator needs to
>    modify the associated Data Records according to the modified Options
>    Template Record.  However, if each node uses another field except for
>    the Observation Domain ID as the scope, the scope field should be
>    considered on a case-by-case basis.
> 
>    The following example describes the cascade connection of IPFIX
>    Mediators.  Router#1 and Mediator#1 export the Metering Process
>    Statistics Option Template.
> 
> 
>           Session#a            Session#b            Session#c
>    Router --------> Mediator#1 --------> Mediator#2 -------->Collector
>    IP:1.1.1.1       IP:2.2.2.2           IP:3.3.3.3
>    SrcPort:10       DstPort:20           DstPort:40
>    ODID:10          SrcPort:30           SrcPort:50
>                     ODID:0               ODID:0
> 
>    Figure H: Cascade connection of IPFIX Mediators.
> 
>    Mediator#2 exports each Option Template and its Data Record with a
>    suitable scope.
> 
>    Session#c Metering Process Statistics Data Records from the Original
>    Exporter:
>       Field Count = 15
>       Scope Count = 12
>       exporterIPv4Address = 1.1.1.1
>       collectorIPv4Address = 2.2.2.2
>       collectorTransportProtocol = 16
>       exporterTransportPort = 10
>       collectorTransportPort = 20
>       observationDomainId = 10
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 22]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
>       exporterIPv4Address = 2.2.2.2
>       collectorIPv4Address = 3.3.3.3
>       collectorTransportProtocol = 16
>       exporterTransportPort = 30
>       collectorTransportPort = 40
>       observationDomainId = 0
>       exportedMessageTotalCount
>       exportedFlowTotalCount
>       exportedOctetTotalCount
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 23]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
> 7.  Security Considerations
> 
>    The IPFIX concentrator uses the IPFIX protocol.  Security
>    considerations about flow information are described in
>    [I-D.ietf-ipfix-protocol].
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 24]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
> 8.  IANA Considerations
> 
>    This document has no actions for IANA.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 25]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
> 9.  References
> 
> 9.1.  Normative References
> 
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119, March 1997.
> 
> 9.2.  Informative References
> 
>    [I-D.dressler-ipfix-aggregation]
>               Dressler, F., Sommer, C., and G. Munz, "IPFIX
>               Aggregation", draft-dressler-ipfix-aggregation-03.txt
>               (work in progress) , June 2006.
> 
>    [I-D.ietf-ipfix-architecture]
>               Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
>               "Architecture for IP Flow Information Export",
>               draft-ietf-ipfix-architecture-12.txt(work in progress) ,
>               September 2006.
> 
>    [I-D.ietf-ipfix-info]
>               Quittek, J., Bryant, S., Claise, B., and J. Meyer,
>               "Information Model for IP Flow Information Export",
>               draft-ietf-ipfix-info-13.txt(work in progress) ,
>               June 2006.
> 
>    [I-D.ietf-ipfix-protocol]
>               Claise, B., "IPFIX Protocol Specification",
>               draft-ietf-ipfix-protocol-23 (work in progress) ,
>               October 2006.
> 
>    [I-D.ietf-psamp-framework]
>               Duffield, N., "A Framework for Packet Selection and
>               Reporting", draft-ietf-psamp-framework-10.txt ,
>               January 2005.
> 
>    [I-D.ietf-psamp-sample-tech]
>               Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.
>               Raspall, "Sampling and Filtering Techniques for IP Packet
>               Selection", draft-ietf-psamp-sample-tech-07.txt ,
>               July 2005.
> 
>    [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
>               "Requirements for IP Flow Information Export(IPFIX)",
>               October 2004.
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 26]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
> Authors' Addresses
> 
>    Atsushi Kobayashi
>    NTT Information Sharing Platform Laboratories
>    3-9-11 Midori-cho
>    Musashino-shi, Tokyo  180-8585
>    Japan
> 
>    Phone: +81-422-59-3978
>    Email: [email-masked]
> 
> 
>    Keisuke Ishibashi
>    NTT Information Sharing Platform Laboratories
>    3-9-11 Midori-cho
>    Musashino-shi, Tokyo  180-8585
>    Japan
> 
>    Phone: +81-422-59-3407
>    Email: [email-masked]
> 
> 
>    Kondoh Tsuyoshi
>    NTT Information Sharing Platform Laboratories
>    3-9-11 Midori-cho
>    Musashino-shi, Tokyo  180-8585
>    Japan
> 
>    Phone: +81-422-59-2419
>    Email: [email-masked]
> 
> 
>    Daisuke Matsubara
>    Hitachi, Ltd., Central Reseach Laboratory
>    1-280 Higashi-koigakubo
>    Kokubunji-shi, Tokyo  185-8601
>    Japan
> 
>    Phone: +81-42-323-1111
>    Email: [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 27]
> 
> Internet-Draft     Reference Model for IPFIX Mediators         June 2007
> 
> 
> Full Copyright Statement
> 
>    Copyright (C) The IETF Trust (2007).
> 
>    This document is subject to the rights, licenses and restrictions
>    contained in BCP 78, and except as set forth therein, the authors
>    retain all their rights.
> 
>    This document and the information contained herein are provided on an
>    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
>    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
>    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
>    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
>    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
>    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Intellectual Property
> 
>    The IETF takes no position regarding the validity or scope of any
>    Intellectual Property Rights or other rights that might be claimed to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; nor does it represent that it has
>    made any independent effort to identify any such rights.  Information
>    on the procedures with respect to rights in RFC documents can be
>    found in BCP 78 and BCP 79.
> 
>    Copies of IPR disclosures made to the IETF Secretariat and any
>    assurances of licenses to be made available, or the result of an
>    attempt made to obtain a general license or permission for the use of
>    such proprietary rights by implementers or users of this
>    specification can be obtained from the IETF on-line IPR repository at
>    http://www.ietf.org/ipr.
> 
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights that may cover technology that may be required to implement
>    this standard.  Please address the information to the IETF at
>    [email-masked].
> 
> 
> Acknowledgment
> 
>    Funding for the RFC Editor function is provided by the IETF
>    Administrative Support Activity (IASA).
> 
> 
> 
> 
> 
> Kobayashi, et al.       Expires December 25, 2007              [Page 28]
> 

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 26 Jul 2007 11:40:27 +0200

Paul,

Just a small comment:

> Why would we not just modify the template and remove these Information

Instead of removing IP addresses you might want to apply anonymization
techniques which preserve prefix information while still preventing
inference of the original addresses. E.g. see CryptoPAN already deployed
by many Netflow tools like "flow-tools":
http://www.cc.gatech.edu/computing/Networking/projects/cryptopan/

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone:  +49 7071 29-70534       Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 26 Jul 2007 11:40:27 +0200

Paul,

Just a small comment:

Regards,
Gerhard

---

From: Paul Aitken <[email-masked]>
Date: Thu, 26 Jul 2007 15:12:51 +0100

Gerhard,

> http://www.cc.gatech.edu/computing/Networking/projects/cryptopan/

Indeed, anonymization is mentioned in section 6.7 of the IPFIX 
requirements, RFC 3917.

However, as far as I can see it's not something that anyone in the WG 
seems to have worked on until now. But since now it appears both in 
Brian's file draft and in Kobayshi-san's mediator draft, perhaps it's 
time we began to consider what the best method might be?

So my question is: what is the value of storing or forwarding anonymised 
information? Since the original data can not be determined from the 
anoymised data, it only serves to indicate that there was some data 
there which was anonymised (ie, the anonymised data is of no value 
itself) - and I can think of a better way to do that, eg send a reduced 
size version of the field with zero-length.

And if it's not necessary to indicate that the field was there then 
surely the best way to anoymise it is to remove it entirely?

---

From: Paul Aitken <[email-masked]>
Date: Thu, 26 Jul 2007 15:12:51 +0100

Gerhard,

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 26 Jul 2007 16:36:04 +0200

Paul,

> time we began to consider what the best method might be?

Just because this issue has not been on the mailing list, this does not
mean that nobody in the community has been working on it. For example,
we have worked on it in the scope of the HISTORY project focusing on
different anonymization techniques and legal issues in Germany.
http://www.history-project.net/index.php?show=anonym
http://www.history-project.net/anonym/index_e.html
http://www7.informatik.uni-erlangen.de/~dressler/publications/pik-2006.pdf

> size version of the field with zero-length.

There is a difference in anonymized data and non-existing data, e.g. if
two anonymized IP addresses are different, you know that the original
ones were different as well, and that they belonged to the same subnet
(if prefix-preserving techniques are deployed). But if you remove the
information, you lose this information.

> surely the best way to anoymise it is to remove it entirely?

Anonymization is very important for academics who always try to convince
network operators to give them some real measurement data for their
research.

Regards,
Gerhard

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 26 Jul 2007 16:36:04 +0200

Paul,

Regards,
Gerhard

---

From: Paul Aitken <[email-masked]>
Date: Thu, 26 Jul 2007 15:45:49 +0100

Gerhard,

These are all very points. Thank you for sharing them here. Perhaps you 
should write an IPFIX anonymisation draft? :-)

---

From: Paul Aitken <[email-masked]>
Date: Thu, 26 Jul 2007 15:45:49 +0100

Gerhard,

---

From: kobayashi atsushi <[email-masked]>
Date: Fri, 27 Jul 2007 00:26:44 +0900

Paul-san and Gerhard-san,

Paul-san, thank you for big comments about mediator draft.
I will reply your comment one step at a time.

Gerhard-san, thank you for your notification about reference.

I think that anonymisation is good solution to prevent to violate privacy
information. Even if the original data can not be determined from the
anonymised data, we can monitor the traffic trend, as follows.

For example,
- How long does each flow continue the session?
- How many packets does each flow send? 
- Proportion of heavy flow or heavy customer. 
- Proportion of short flow or one packet flow.  
- How many flows does each network prefix included?
To do it, anonymization technique needs to preserve prefix, just like
Gerhard reference.

And furthermore, this data becomes useful data by comparing between past
data and simulating future data.

And, pairs of comparison are considered several type.

- each peering points
- mobile network and broadband network
- tariff system: fixed amount rate and metered rate
:

Above data can not be measured, if associated field becomes zero or
removal.

Best Regards,
Atsushi KOBAYASHI

On Thu, 26 Jul 2007 15:12:51 +0100

> surely the best way to anoymise it is to remove it entirely?

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

---

From: kobayashi atsushi <[email-masked]>
Date: Fri, 27 Jul 2007 00:26:44 +0900

For example,

- each peering points

Best Regards,
Atsushi KOBAYASHI

---

---

From: kobayashi atsushi <[email-masked]>
Date: Sun, 29 Jul 2007 04:39:57 +0900

Hi Paul,
 
Thank you for your valuable comments.
Please see in-line.

Atsushi KOBAYASHI

On Wed, 25 Jul 2007 23:39:11 +0100

> "This node" -> "A mediator"

Yes. I will correct them in next version. 

> It's unclear what this last line means.

"this" indicates this draft.
This document describes the model of the solution scenario using IPFIX Mediator
which refer to chapter 5. 

> Can you cite some references for this?

I can't cite some references now. Until submitting the next version, I will
search for some references.

> What do you mean by "multifaceted"?

Simply, I mean that the variety of packets, such as IPv4 and IPv6, are passed
thought in the same network. Especially, MPLS network handles the
several customer's traffic as VPN traffic, such as pseudo wire or L3VPN.

I means that networks are integrating variety of traffic.

I will add the explanation in this paragraph.

> "can not be fed *to* each customer"

yes. I will correct it in the next version.

> It's worth defining what mediation is.

I will add the description about Flow Mediation and IPFIX protocol
Mediation presented by my slide.

> Also, what are "renewed Flow Records"?

This part is described about Flow Mediation.

I means that the "renewed Flow Records" is modified Flow Records or
aggregated Flow Records.

Modification of Flow Records means that some fields are added and deleted,
and whose value are modified.

I will adds the description in the next version.

> Must the mediator understand the content? eg, what about Enterprise 

Mediator doesn't need to understand all content, as semantic. After decoding
by the collecting process, Flow Records are distributed in accordance
with specified elements contents, such as input IF indexes or Peering AS.
In this case, Mediator doesn't need to understand other field contents.
In the distribution of Flow Records, Some fields which should be understood
are restricted.

> "may optionally have Metering Processes and Storing Processes".

Yes. I will correct them in the next version.

> This last line is unclear.

In next version, I will add the description about what is IPFIX Mediator.
I means that IPFIX Mediator is generic name of the several nodes, such as
the IPFIX proxy, IPFIX firewall and IPFIX concentrator.

> >       An IPFIX Proxy acts as a proxy for Original Exporter, which hosts
Yes.

> This last line is unclear.

IPFIX proxy does not send the the information about an Original
Exporter, such as "exporterIPv{4|6}Address" to the Collector.

> Does it block records, or modify them? eg, does it anonymise them?
I think that above functions are included in the IPFIX Firewall.
At least, IPFIX Firewall has one function of above functions, such as
filtering, modifying and anonymizing.

I will add the description about it in the next version.
> "the values of specific Information Elements"

Yes. I will correct this term in the draft.
> - and presumably this is a key part of a firewall?

Yes.
But, the modification process is not limited as the functions of IPFIX
firewall.
If the Modification Process adds the BGP Next Hop Address into the Flow
Records, this node is not implied to the IPFIX Firewall.

> How does information get *out* of the Storing Process?

This part is out of scope of this document.
As solution, several solution can be considered.

In case of our system, other node, such as analyzer, submitted the query
that contains the specified time slot as XML, IPFIX Mediator replies this
query by replaying the NetFlow packets. 
> To all collectors, or to a subset?

To a subset.
I mean that the classified Flow Records are exported to the specified Collector.

> Arguably a whole new set of Observation Domain values applies on the 

This part need a discussion with IPFIX members.
If IPFIX Proxy handles one exporting session and one collecting session,
simply IPFIX Proxy doesn't need to change the observation domain values.

I think, If IPFIX Proxy handles multiple session on the both sides,
IPFIX Proxy needs to assign the new Observation Domain values.

> Process, and/or to the Exporting Process.

Good idea. Roughly, I can image following figure.

      +--------------------------------------------------------------+
      |                        IPFIX Mediator                        |
      | .----------.                                     .---------. |
      | |          |  .-------------------------------.  |         | |
      | |Collecting|  |        Metering Process       |  |Exporting| |
      | |Process   |  |.-------.  .-------.  .-------.|  |Process  | |
      | |          |--->sub    |-->sub    |->|sub    |-->|         | |
    IPFIX          |  ||process|  |process|  |process||  |         IPFIX
    --> |          |.->|#1     |  |#2     |  |#3     ||  |         |-->
      | |          || |'-------'  '-------'  '-------'|  |         | |
      | |          || '----|----------|----------|----'  |         | |
      | |          ||      |          |          |       |         | |
      | |          ||   .--\/---------\/---------\/--.   |         | |
      | |          |'---|       Storing Process      |<--|         | |
      | |          |--->|                            |-->|         | |
      | |          |    '----------------------------'   |         | |
      | |          |------------------------------------>|         | |
      | '----------'                                     '---------' |
      +--------------------------------------------------------------+

> >    forwarding several Metering Processes.  In addition, the Collecting
Yes. 
Flow Records can be duplicated by forwarding several Metering Processes
or Exporting Processes.

> >    next process.  Theprocess has a filtering function and selects Flow

Thanks.

> As a general question, is it valid to aggregate fields which were not 

I think that the aggregate key field does not depend on the original key
fields.

> Why would we not just modify the template and remove these Information 

This point has been already discussed in ML.

> Surely this would/should be user configurable?

I means this is example. Which field is selected in order to distribute Flow
Records should be configurable.
I will modify next version. It is too short description
 
> What is the "storing instruction" ?

The Flow Records which are wanted to store by user might not be equal to
received Flow Records. The meaningless fields could be discarded by user.
The storing instruction means the configured information by user.
It indicates fields which should be stored and field which should not be
stored.

I will adds the explanation in next version. And also, I used "storing
instruction" and "storing rule" as same meaning. I will correct it.

> How does it retrieve them?

Simply, the specified past Flow Records can be retrieved on the basis of
time period which is given by user. The retrieving mechanism is out of
scope of this document.

> >    Flow Record.  An IPFIX Proxy SHOULD reuse the "Export Time" of
Yes. I will correct it.

> "Template". Please be sure to capitalise IPFIX terminology!
Yes. I will correct it.

> Surely that's a loss of privacy?

It is depends on the role of IPFIX Mediator.
If it is IPFIX Firewall or IPFIX Proxy, exporting Exporter IP address
becomes to grow the vulnerability.
On the other hand, if it is other nodes, such as concentrator, Exporter
IP address is important information for traffic analysis, such as traffic
engineering.

In case of making traffic matrix, Exporter IP address can indicate the
ingress router of network domain.
> Some text seems to be missing here?

Oops, I miss the period. I will correct it.

> "Next, a second level Mediator"
Yes. I will correct it.

> The bottom left router should be "router#3"
Yes. I will correct it.

> >    An IPFIX Mediator distributes Flow Records based on Flow Record
Yes. I will correct it.

> It's unclear to me what this means.

Surely, it is too short explanation. For example, if an IPFIX Mediator
distributes Flow Records on the basis of input IF indexes which
indicates customer, measuring total traffic volume by each Collector can
indicate each customer's accounting information.

On careful thought, it is better that this sentence is omitted.

> "we"? -> The mediator, perhaps?
I was confused how to use "we". I mean it is network service provider. 
The Mediator is preferable.

> suspicious if the count was still 1 after some time.
Yes.

> Could you use real-world values in the examples here and below?
Is it preferable using private address? 
Surely, the destination port number should be 4739.

---

---

From: kobayashi atsushi <[email-masked]>
Date: Sun, 29 Jul 2007 04:39:57 +0900

Hi Paul,

Atsushi KOBAYASHI

Yes.

Yes.

To a subset.

Yes. 

Thanks.

 

Yes. I will correct it.

Yes. I will correct it.

Yes. I will correct it.

Yes. I will correct it.

Yes. I will correct it.

Yes.

---

---

From: Paul Aitken <[email-masked]>
Date: Sun, 29 Jul 2007 11:34:32 +0100

Kobayashi-san,

Here with a few replies to some of your points. I was happy with your 
replies to all the other points, so I snipped out all that text for brevity.

> which refer to chapter 5. 

"Solution" to what? First there would have to be a problem to solve.

> and whose value are modified.

That's two different kinds of modification:

1. changing the value of the fields
2. changing the template and record structure (adding / removing fields)

It would be good to make this clear - and indicate when each would be done.

> with specified elements contents, such as input IF indexes or Peering AS.

If the mediator doesn't understand the content, then it cannot do this. 
Or at least, not do it very well.

eg, if it sees that a field is one octet, it may choose to distribute to 
four collectors as follows:

0x00 - 0x3F -> Collector 1
0x40 - 0x7F -> Collector 2
0x80 - 0xBF -> Collector 3
0xC0 - 0xFF -> Collector 4

However, the octet may only contain 6 bits of information (ie, 0x00 - 
0x3F) so all the traffic will go to Collector 1.

Or the field may be a counter - so traffic will be divided across the 
collectors, depending how much was counted. That doesn't seem to make a 
lot of sense (except perhaps, a special collector to analyse extra-small 
or extra-large flows).

> In the distribution of Flow Records, Some fields which should be understood

You mean, distribution can only be made according to some well 
understood fields?

> the IPFIX proxy, IPFIX firewall and IPFIX concentrator.

In another mail, I had suggested that since this draft is already quite 
complex, it might be better to divide into seperate drafts covering 
different functions. eg, from the titles above, you could have three 
drafts describing proxy, firewall and concentrator. You would still be 
able to made a mediator product which complies with all three of these 
drafts together.

> query by replaying the NetFlow packets. 

OK. I think it would be good to add a small note indicating that data 
may be retrieved from the Storing Process in different ways which are 
outside the scope of the current work.

> simply IPFIX Proxy doesn't need to change the observation domain values.

I agree, because it's a transparent device, ie it's invisible to the 
collector.

> IPFIX Proxy needs to assign the new Observation Domain values.

I think it would be possible for a device to receive information from 
other devices, process the information and re-report the information as 
if it had been observed locally.

Viewed another way, we could have three IPFIX devices (A, B, C) 
reporting to a fourth device (D) as so:

	+----------+    +----------+    +----------+
	| device A |    | device B |    | device C |
	+----------+    +----------+    +----------+
	      |               |               |
	      +---------------+---------------+
	                      |
	                +----------+
	                | device D |
	                +----------+

I believe device D could report a new observation domain as so:

	+----------------------------------------------+
	|                                              |
	| +----------+    +----------+    +----------+ |
	| | device A |    | device B |    | device C | |
	| +----------+    +----------+    +----------+ |
	|                                              |
	|                                     device D |
	+----------------------------------------------+

In this case, device D would use its own Observation Domain IDs and not 
have to report OD ID 0.

> Good idea. Roughly, I can image following figure.

Yes, this is exactly what I had in mind.

> I think that the aggregate key field does not depend on the original key

For sure it's possible - even if statistically it might not make any sense.

> ingress router of network domain.

Very true. So it's worth indicating this in the draft.

> indicate each customer's accounting information.

I see how this could work if the mediator knows which interface connects 
to which customer or it's able to tell the collector by some means.

> On careful thought, it is better that this sentence is omitted.

Oh?

> The Mediator is preferable.

Sometimes people write "I" or "we" instead of the device, eg "I will 
export" -> no, you personally won't export anything. Your device will 
export...

> Is it preferable using private address?

You could use 10. or 192. addresses.

> Surely, the destination port number should be 4739.

Exactly. And also real looking exporterTransportPort, 
observationDomainId and so on.

Thanks.

---

From: Paul Aitken <[email-masked]>
Date: Sun, 29 Jul 2007 11:34:32 +0100

Kobayashi-san,

Oh?

Thanks.

---

From: kobayashi atsushi <[email-masked]>
Date: Wed, 01 Aug 2007 02:08:58 +0900

Hi Paul,

Please see in-line.

On Sun, 29 Jul 2007 11:34:32 +0100

> "Solution" to what? First there would have to be a problem to solve.

I see. I will add problem statements.

Yes.

> It would be good to make this clear - and indicate when each would be done.

I don't indicate that all functions are needed in Mediator. At first, I
would like to define the function of changing the Flow Records.

In next version, I will think more about description.

> > with specified elements contents, such as input IF indexes or Peering AS.

It might be improper description. I meant that "content" is value of
some information elements. Did I misunderstand "content"?

If the Mediator distributes Flow Records in accordance with Peering AS,
the Mediator must understand the value of Peering AS fields. But, the
Mediator does not need to see the value of other fields.

> You mean, distribution can only be made according to some well 
Yes. At least, mediator does not need to see the value of all fields. 
Even if the mediator can not recognize the value of some enterprise
information element, what is necessary is just to forward the Flow Records
with its fields.

> able to made a mediator product which complies with all three of these 

I would like to know other members comments.

> outside the scope of the current work.
Thank you. I will add a small note.

> I agree, because it's a transparent device, ie it's invisible to the 

invisible?

At least, the source ip address of IPFIX session is changed to IPFIX
proxy address. The collector presumes this address indicates the original
exporter and the observation domain is attached to this exporter.

> reporting to a fourth device (D) as so:

I can consider as you mentioned. I think that setting ODID 0 is exactly
not wrong according to IPFIX protocol draft, as follows.

           The Observation Domain ID 
           SHOULD be 0 when no specific Observation Domain ID is 
           relevant for the entire IPFIX Message.  For example, when 
           exporting the Exporting Process Statistics, or in case of 
           hierarchy of Collector when aggregated data records are 
           exported.  

It might depend on the policy of device D.

> Yes, this is exactly what I had in mind.
I will add above figure.

> For sure it's possible - even if statistically it might not make any sense.

Please let me know in what kind of case it does not make any sense.

Yes.

Yes.

> > On careful thought, it is better that this sentence is omitted.
This sentence is not consistent with the meaning of the paragraph.
I will improve the paragraph.

> export" -> no, you personally won't export anything. Your device will 
Yes. Thank you.

> observationDomainId and so on.

OK.

---

---

From: kobayashi atsushi <[email-masked]>
Date: Wed, 01 Aug 2007 02:08:58 +0900

Hi Paul,

Please see in-line.

Yes.

invisible?

I will add above figure.

Yes.

Yes.

Yes. Thank you.

OK.

---