[IPFIX] Mediator framework: review

[Gerhard Muenz <[e-mail]>]

Dear Atsushi, all,

I reviewed the mediator framework draft.

In my opinion, it already is in a very good shape. The scope is clear
and the description of the different mediator functions is comprehensive.

I'm not sure about the "Flow-based Collector Selection". It does not
seem to be a new function but rather a use-case of the "Flow Selection
Function" (plus Exporting Process, see comments below).

Probably, you should not reference future drafts that are supposed to
provide technical solutions (such as IPFIX anonymization and aggregation
drafts) because we do not know how the solutions will look like. RFC3917
does not reference any early IPFIX protocol draft, either.

Some more examples for specific mediator use-cases might be useful.

Regards,
Gerhard



> IPFIX Working Group                                         A. Kobayashi
> Internet-Draft                                                H. Nishida
> Intended status: Informational                               NTT PF Lab.
> Expires: May 8, 2009                                           B. Claise
>                                                            Cisco Systems
>                                                         November 4, 2008
> 
> 
>                        
> IPFIX Mediation: Framework
> 
>                 
> draft-ietf-ipfix-mediators-framework-01
> 
> 
> 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 May 8, 2009.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                  [Page 1]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
> Abstract
> 
>    This document describes a framework for an IPFIX Mediation.  This

"for an IPFIX Mediator" or "for IPFIX Mediation"

>    framework details an IPFIX Mediation reference model and the
>    components of the IPFIX Mediation device (IPFIX Mediator).
> 
> 
> Table of Contents
> 
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
>    3.  IPFIX Mediation Reference Model  . . . . . . . . . . . . . . .  9
>    4.  IPFIX Mediation Functional and Logical Blocks  . . . . . . . . 12
>      4.1.  Collecting Process . . . . . . . . . . . . . . . . . . . . 12
>      4.2.  Exporting Process  . . . . . . . . . . . . . . . . . . . . 12
>      4.3.  Intermediate Process . . . . . . . . . . . . . . . . . . . 12
>        4.3.1.  Flow Selection Function  . . . . . . . . . . . . . . . 12
>        4.3.2.  Flow-based Collector Selection Function  . . . . . . . 13
>        4.3.3.  Aggregation Function . . . . . . . . . . . . . . . . . 13
>        4.3.4.  Correlation Function . . . . . . . . . . . . . . . . . 14
>        4.3.5.  Modification Function  . . . . . . . . . . . . . . . . 15
>      4.4.  IPFIX File Writer/Reader . . . . . . . . . . . . . . . . . 16
>      4.5.  Flow Expiration  . . . . . . . . . . . . . . . . . . . . . 17
>      4.6.  Information Model  . . . . . . . . . . . . . . . . . . . . 18
>      4.7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18
>    5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
>    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
>    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
>      7.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
>      7.2.  Informative References . . . . . . . . . . . . . . . . . . 22
>    Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 24
>    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
>    Intellectual Property and Copyright Statements . . . . . . . . . . 26
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                  [Page 2]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
> 1. Introduction
> 
> 
>    IPFIX Mediation reroutes, replicates, filters, aggregates,
>    correlates, or modifies Flow Records/Packet Reports or changes a
>    transport protocol.  This document describes the framework for IPFIX
>    Mediation.  The motivation for the IPFIX Mediation standard comes
>    from the need for flow-based measurement system support for large-
>    scale networks, interdomain networks, and coexistence with
>    traditional Exporters as described in detail in
>    [I-D.ietf-ipfix-mediator-ps].  The standard specification requires a
>    definition of IPFIX Mediation and IPFIX Mediation device (IPFIX
>    Mediator).

I would not introduce "IPFIX Mediation device" as a synonym for "IPFIX
Mediator".

> 
>    This document is organized as follows.  Section 2 describes
>    terminology related to IPFIX Mediation.  Section 3 describes a high
>    level reference model.  Section 4 details the components of the IPFIX
>    Mediator.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                  [Page 3]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
> 2. Terminology
> 
> 
>    The terms in this section are in line with those in the IPFIX
>    specification document [RFC5101] and the PSAMP specification document
>    [I-D.ietf-psamp-protocol].  Additional terms required for the IPFIX

Terms from RFC5101 and psamp-protocol should not be repeated.

>    Mediation are also defined with those in the IPFIX Mediator problem
>    statement [I-D.ietf-ipfix-mediator-ps].  All these terms are
>    capitalized in this document.
> 
>    Observation Point
> 
>       An Observation Point is a location in the network where IP packets
>       can be observed.  Examples include: a line to which a probe is
>       attached, a shared medium, such as an Ethernet-based LAN, a single
>       port of a router, or a set of interfaces (physical or logical) of
>       a router.
> 
>       Note that every Observation Point is associated with an
>       Observation Domain (defined below), and that one Observation Point
>       may be a superset of several other Observation Points.  For
>       example, one Observation Point can be an entire line card.  That
>       would be the superset of the individual Observation Points at the
>       line card's interfaces.
> 
>    Observation Domain
> 
>       An Observation Domain is the largest set of Observation Points for
>       which Flow information can be aggregated by a Metering Process.
>       For example, a router line card may be an Observation Domain if it
>       is composed of several interfaces, each of which is an Observation
>       Point.  In the IPFIX Message it generates, the Observation Domain
>       includes its Observation Domain ID, which is unique per Exporting
>       Process.  That way, the Collecting Process can identify the
>       specific Observation Domain from the Exporter that sends the IPFIX
>       Messages.  Every Observation Point is associated with an
>       Observation Domain.  It is RECOMMENDED that Observation Domain IDs
>       also be unique per IPFIX Device.
> 
>    Flow Key
> 
>       Each of the fields that:
> 
>       1. belong to the packet header (e.g., destination IP address),
> 
>       2. are a property of the packet itself (e.g., packet length),
> 
>       3. are derived from packet treatment (e.g., Autonomous System (AS)
>       number),
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                  [Page 4]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
>       and that are used to define a Flow are termed Flow Keys.
> 
>    Flow Record
> 
>       A Flow Record contains information about a specific Flow that was
>       observed at an Observation Point.  A Flow Record contains measured
>       properties of the Flow (e.g., the total number of bytes for all
>       the Flow's packets) and usually characteristic properties of the
>       Flow (e.g., source IP address).
> 
>    Packet Reports
> 
>       Packet Reports comprise a configurable subset of a packet's input
>       to the Selection Process, including the Packet Content,
>       information relating to its treatment (for example, the output
>       interface), and its associated selection state (for example, a
>       hash of the Packet Content).
> 
>    Exporting Process
> 
>       The Exporting Process sends Flow Records to one or more Collecting
>       Processes.  The Flow Records are generated by one or more Metering
>       Processes.
> 
>    Exporter
> 
>       A device that hosts one or more Exporting Processes is termed an
>       Exporter.
> 
>    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.
> 
>    Collecting Process
> 
>       A Collecting Process receives Flow Records from one or more
>       Exporting Processes.  The Collecting Process might process or
>       store received Flow Records, but such actions are out of the scope
>       of this document.
> 
>    Collector
> 
>       A device that hosts one or more Collecting Processes is termed a
>       Collector.
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                  [Page 5]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
>    IPFIX Message
> 
>       An IPFIX Message is a message originating at the Exporting Process
>       that carries the IPFIX records of this Exporting Process and whose
>       destination is a Collecting Process.  An IPFIX Message is
>       encapsulated at the transport layer.
> 
>    Information Element
> 
>       An Information Element is a protocol and encoding-independent
>       description of an attribute that may appear in an IPFIX Record.
>       The IPFIX information model [RFC5102] defines the base set of
>       Information Elements for IPFIX.  The type associated with an
>       Information Element indicates constraints on what it may contain
>       and also determines the valid encoding mechanisms for use in
>       IPFIX.
> 
>    IPFIX Mediation
> 
>       An IPFIX Mediation is a generic term for functions doing something
>       for Flow Records, Packet Reports, and IPFIX Messages.  IPFIX
>       Mediation is located in between components: Metering Processes,
>       Exporting Processes, Collecting Processes, and other applications.
>       IPFIX Mediation can be included in any IPFIX Devices.  IPFIX
>       Mediation consists of a set of some of the following functions:
> 
>       *  rerouting input Flow Records/Packet Reports to an appropriate
>          Collecting Process
> 
>       *  replicating input Flow Records/Packet Reports
> 
>       *  filtering and selecting input Flow Records/Packet Reports
> 
>       *  aggregating input Flow Records/Packet Reports based on new Flow
>          Keys
> 
>       *  correlating a set of Flow Records/Packet Reports for creating
>          new Flow Records/Packet Reports with new metrics
> 
>       *  modifying input Flow Records/Packet Reports
> 
>       *  changing transport protocols that carry IPFIX Messages
> 
>       The modification of Flow Records/Packet Reports includes these
>       processes:
> 
>       *  changing the value of specified Information Elements
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                  [Page 6]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
>       *  adding new Information Elements by deriving further Flow or
>          packet properties from existing fields or calculating new
>          metrics
> 
>       *  deleting specified Information Elements.
> 
>       IPFIX Mediation can be included in any device, such as routers,
>       switches, NMS (Network Management Systems), or stand-alone
>       devices.
> 
>    Flow-Based Collector Selection
> 
>       The Flow-Based Collector Selection evaluates an input Flow Record/
>       Packet Report based on the value of the specified Information
>       Element and then selects a Collector for each input Flow Record/
>       Packet Report.
> 
>    IPFIX Mediator
> 
>       An IPFIX Mediator contains one or more functions defined in IPFIX
>       Mediation.  The IPFIX Mediator can be a stand-alone or a virtual
>       device.  It also contains one or more Collecting Processes and one
>       or more Exporting Processes.
> 
>    Original Exporter
> 
>       An Original Exporter is an IPFIX Device that hosts Observation
>       Points where IP packets can be directly observed.
> 
>    IPFIX Proxy
> 
>       An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages
>       from an Original Exporter and sends IPFIX Messages to one or more
>       Collectors.  It may alter part of an IPFIX Message to comply with
>       IPFIX Protocol specifications.  It may also change the type of
>       transport protocol, such as UDP, TCP, SCTP, and PR-SCTP, and
>       convert a legacy protocol message to an IPFIX Message, if
>       necessary.
> 
>    IPFIX Concentrator
> 
>       An IPFIX Concentrator is an IPFIX Mediator that receives Flow
>       Records/Packet Reports, aggregates them, then exports the
>       aggregated Flow Records.
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                  [Page 7]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
>    IPFIX Distributor
> 
>       An IPFIX Distributor is an IPFIX Mediator that reroutes input Flow
>       Records/Packet Reports based on the result of Flow-Based Collector
>       Selection.  It may filter or replicate input Flow Records/Packet
>       Reports, if necessary.
> 
>    IPFIX Masquerading Proxy
> 
>       An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out
>       a part of the data of input Flow Records/Packet Reports according
>       to configured policies.  It can thus, for example, hide the
>       network topology information or customers' IP addresses.
> 
>    Intermediate Process
> 
>       An Intermediate Process in IPFIX Mediators can be considered as a
>       partial Metering Process taken from the Metering Process in
>       Original Exporters as described in [RFC3917].

I do not like the definition of IP as "partial MP". This creates
confusion and makes it difficult to distinguish MPs and IPs.

> 
>       The Intermediate Process generates new sets of Data Records/Packet
>       Reports from input Data Records/Packet Reports.
> 
>    Mediator Observation Domain
> 
>       An IPFIX Mediator does not host the Observation Points and

Why should we disallow IPFIX Mediators which also have native
Observation Points?

>       Observation Domain.  The Observation Domain ID in the IPFIX header
>       sent by the IPFIX Mediator also indicates the largest set of
>       Observation Points from the viewpoint of a Collector.  However,

This seems to be too generic. The ODID issued by the mediator should
identify the set of ODs/OPs the exported records belong to.
It does not always have to be the "largest set of OPs", it can be a subset.

As an example, the Mediator may be configured not to merge records from
different OPs at all. In this case, we can keep the old OIDs. Or it may
be configured to merge records from a specific subset of OPs only.

>       this value does not indicate the physical entity of an Original
>       Exporter.
> 
>    Transport Session Information
> 
>       The Transport Session is specified in [RFC5101].  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, and transport protocol}.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                  [Page 8]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
> 3. IPFIX Mediation Reference Model
> 
> 
>    The figure below shows the high-level reference model for IPFIX
>    Mediation based on [I-D.ietf-ipfix-architecture].  This figure covers
>    the various possible scenarios that can exist in an IPFIX measurement
>    system.
> 
> 
>    +---------------------------+    +---------------------------+
>    | Collector {l}             |    | Collector {k}             |
>    |[*Application(s)]          |    |[*Application(s)]          |
>    |[IPFIX File Reader/Writer] |    |[IPFIX File Reader/Writer] |
>    |[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 in to Observation Points
> 
>    Figure A: Reference Model for IPFIX Mediation.
> 
>    The various functional components are indicated within brackets [].
>    The functional components within [*] are not part of
>    [I-D.ietf-ipfix-architecture].

Hm. Intermediate Process as well as IPFIX reader/writer are not part of
ipfix-architecture either.

BTW: IPFIX reader/writer are considered as special types of CPs and EPs.

> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                  [Page 9]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
>    The figure below shows the basic IPFIX Mediator component model.  The
>    IPFIX Mediator is formally defined to consist of one or more
>    Collecting Processes, zero or more Intermediate Processes, and one or
>    more Exporting Processes.  Basically, IPFIX Mediator devices, i.e.,
>    IPFIX Proxy, IPFIX Masquerading Proxy, IPFIX Distributor, and IPFIX
>    Concentrator, described in [I-D.ietf-ipfix-mediator-ps], are composed
>    of these components.
> 
> 
>             IPFIX(Flow Records/Packet Reports)
>                               ^
>                             ^ |
>    +------------------------|-|---------------------+
>    | IPFIX Mediator         | |                     |
>    |                        | |                     |
>    |  .---------------------|-+-------------------. |
>    | .----------------------+--------------------.| |
>    | |          Exporting Process (es)           |' |
>    | '----------------------^--------------------'  |
>    |                        | |                     |
>    |  .---------------------|-+-------------------. |
>    | .----------------------+--------------------.| |
>    | |    Intermediate Process (es) (optional)   |' |
>    | '----------------------^--------------------'  |
>    |                        | |                     |
>    |  .---------------------|-+-------------------. |
>    | .----------------------+--------------------.| |
>    | |          Collecting Process (es)          |' |
>    | '----------------------^--------------------'  |
>    +------------------------|-|---------------------+
>                             |
>             IPFIX(Flow Records/Packet Reports)
> 
>    Figure B: IPFIX Mediator Basic Component Model.
> 
>    An Original Exporter with a Mediation function is modeled as follows.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 10]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
>                IPFIX (Flow Records/Packet Reports)
>                                ^ ^
>    +---------------------------|-|------------------------+
>    | Original Exporter         | |                        |
>    |                           | |                        |
>    |     .---------------------|-+-------------------.    |
>    |    .----------------------+--------------------.|    |
>    |    |           Exporting Process(es)           |'    |
>    |    '----------------------^--------------------'     |
>    |                           | |                        |
>    |     .---------------------|-+-------------------.    |
>    |    .----------------------+--------------------.|    |
>    |    |          Intermediate Process(es)         |'    |
>    |    '---------^-----------------------^---------'     |
>    |              |Flow Record or         |               |
>    |              |        Packet Reports |               |
>    | .------------+----------.  .---------+-------------. |
>    | | Metering Process {i}  |..| Metering Process {n}  | |
>    | '------------^----------'  '---------^-------------' |
>    |              |                       |               |
>    | .------------+----------.  .---------+-------------. |
>    | | Observation Point {i} |..| Observation Point {n} | |
>    | '------------^----------'  '---------^-------------' |
>    +--------------|-----------------------|---------------+
>                   |                       |
>             Packets coming in to Observation Points
> 
>    Figure C: Component Model for Original Exporter with Mediation.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 11]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
> 4. IPFIX Mediation Functional and Logical Blocks
> 
> 
>    The section describes the details of each component and examples
>    applicable to that component for IPFIX Mediation and IPFIX Mediator.
> 
> 4.1. Collecting Process
> 
> 
>    The Collecting Processes described in [RFC5101] receive Flow Records/
>    Packet Reports with information relating to their treatment in the
>    Metering Process and Exporting Process in the Original Exporter, such
>    as sampling rate, IPFIX header information, and Transport Session
>    Information.  The Collecting Processes forward the set of data to
>    multiple components: Intermediate Processes and Exporting Processes.
>    In other words, the processes may duplicate received Flow Records/
>    Packet Reports and forward them to multiple components in sequence or
>    in parallel.
> 
> 4.2. Exporting Process
> 
> 
>    The Exporting Processes described in [RFC5101] forward Flow Records/

better verb for "forward"? e.g. "transmit"?

>    Packet Reports to one or multiple Collectors.  The processes manage
>    the reporting Template and make IPFIX Messages.
> 
> 4.3. Intermediate Process
> 
> 
>    Intermediate Processes generate new sets of Flow Records/Packet
>    Reports from input Flow Records/Packet Reports with IPFIX header
>    information "Export Time" and "Observation Domain ID".  The processes

I would not call it "IPFIX header information" because there are no
IPFIX Messages at the input of the Intermediate Process, only Records.
Maybe "context information collected at the Collecting Process"?

>    host one of several functions defined below or a combination of them,
>    in any sequence or in any set.  In the case of a combination, the
>    output of each function can be the input of other functions.  The
>    following subsections show the details of each function.
> 
> 4.3.1. Flow Selection Function
> 
> 
>    The Flow Selection function determines which input Flow Records/
>    Packet Reports are selected by matching under a filtering policy and
>    then forwards them to the next processes or functions.  The function
>    is similar to the Selection Process described in
>    [I-D.ietf-psamp-framework].  The function covers several selection
>    techniques, such as property match filtering and Flow selection,
>    which are described in [I-D.ietf-psamp-framework] and
>    [I-D.peluso-flowselection], respectively.  In property match
>    filtering, if the value of a specified Information Element equals a
>    configured value, the function selects Flow Records/Packet Reports to
>    forward.
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 12]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
> 4.3.2. Flow-based Collector Selection Function
> 
> 
>    The Flow-based Collector Selection function determines to which
>    Collector input Flow Records/Packet Reports are exported.  The
>    function may also determine the type of Transport Session.  The

This functional description conflicts with the Exporting Process. In my
opinion, the Exporting Process holds the information about the
Collectors, transport protocol etc.

>    function evaluates the value of a specified Information Element in
>    input Flow Records/Packet Reports and then selects the Collector.

So, what is the difference between Flow-Based Colelctor Selection
Function and Flow Selection Function plus Exporting Process?

I'm not sure if Flow-based Collector Selection should be a function of
its own. I would rather say that it describes a use-case of one or
multiple Flow Selection Functions and Exporting Processes:

    +--> Flow Selector 1 -> EP 1
----+
    +--> Flow Selector 2 -> EP 2


>    These selection criteria are similar to the property match filtering
>    in Mediator Selection Function.
> 
>    Applicable examples include exporting Flow Records/Packet Reports to
>    a dedicated Collector on the basis of customers or organizations
>    peering.  The function classifies Flow Records/Packet Reports on the
>    basis of a peering AS number, as shown in the following figure.  The
>    set of classified Flow Records/Packet Reports is exported to a
>    dedicated Collector on the basis of the peering AS number.
> 
>            .----------------------------.
>            | Intermediate Process       |
>            |   .----------------------. |
>            |   | Flow-Based Collector | |
>            |   | Selection Function   | |
>            |   |                      | |
>            |   |     Peering AS #10   | |
>            |   |  +-------------------+-+---> Collector #1
>            |   |  |  Peering AS #20   | |
>    Flow  --+---+--+-------------------+-+---> Collector #2
>    Records |   |  |  Peering AS #30   | |
>            |   |  +-------------------+-+---> Collector #3
>            |   '----------------------' |
>            '----------------------------'
> 
>    Figure D: Exporting classified Flow Records to dedicated Collector.
> 
> 4.3.3. Aggregation Function
> 
> 
>    The Aggregation function creates aggregated Flow Records from input
>    Flow Records/Packet Reports.  The aggregation method is divided into
>    three types:
> 
>    Choosing Shorter Flow Key
> 
>       Choosing a shorter Flow Key than the Flow Key of input Flow

A "shorter Flow Key" would be an IP address of 8 bits. That is not what
you mean. You rather decrease the number of fields considered as Flow Keys.

>       Records, such as three, two, or a single Flow Key, can create more

"Flow Key field"

>       aggregated Flow Records.  The function gathers Flow Records/Packet
>       Reports within a given interval time and then distinguishes Flow
>       Records/Packet Reports that have common properties.  If values of

It sounds strange to distinguish records that have common properties.
You rather want to merge them.

>       a given key field are the same, that means those Flow Records/
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 13]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
>       Packet Reports have common properties, and the function merges
>       them in accordance with aggregation rules described in
>       [I-D.dressler-ipfix-aggregation].
> 
>       In addition, the function can create statistical data and
>       subsidiary information related to the aggregated Flow Records.
>       Examples include the number of input Flow Records/Packet Reports,
>       the given interval time, and a set of a new Flow Key.

"a new set of Flow Keys"
(a Flow Key is a single field!)

> 
>    Time Composition
> 
>       Time composition is defined as aggregation with the same Flow Key

"identical Flow Key values"

>       for long-running Flows.  The function may also compute Flow
>       Records statistics, such as average, maximum, and minimum value of
>       each counter.  The statistics help to visualize the behavior of
>       traffic volume over a long time period.
> 
>       As another approach, the function collects Flow Records/Packet
>       Reports of a shorter time period from an Original Exporter, and
>       then computes these statistics.  Even if output Flow Records of
>       the function indicate a general time period, the accuracy of the
>       minimum, maximum, and average value can be improved.

Where is the difference to what you described in the preceding paragraph?

> 
>    Space Composition
> 
>       Space composition is defined as aggregation on a larger
>       Observation Domain or on a set of Observation Points.  In that
>       case, a Flow key can be applied to other properties, such as

What do you mean by "a Flow Key can be applied to <something>"?

>       Exporter IP address and Observation Domain ID.
> 
>       In addition, a group identifier indicating a spatial Observation
>       Domain can also become a new Flow Key. For example, a group can
>       indicate an area on an ISP network, or a link aggregation
>       interface composd of physical interfaces.  The group can also make
>       a relation to a set of values of specified Information Elements in
>       Flow Records by the configuring rule.  After converting from the
>       values of specified Information Elements to the group identifier,
>       the function can create aggregated Flow Records by a general
>       aggregation process.
> 
> 4.3.4. Correlation Function
> 
> 
>    The Correlation function creates new metrics from by evaluating the
>    correlation among sets of Flow Records/Packets Records.  These sets
>    can be Flow Records gathered during a certain period, a pair of
>    consecutive Packet Reports, or Packet Reports exported by different
>    Exporters indicating the same packet.  After offering new metrics,
>    the function outputs Flow Records with the new metrics field.
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 14]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
>    Applicable examples are as follows.
> 
>    o  One way delay follows from correlating Packet Reports exported
>       from different Exporters on the path.
> 
>    o  Packet interval time, or jitter, follows from correlating
>       consecutive Packet Reports exported from the same Exporter.
> 
>    o  Difference values follow from correlating Flow Records observed at
>       ingress or egress interfaces.  The values help to confirm the
>       result of a queueing or rate-limiting function.
> 
>    o  Average/maximum/minimum values follow from correlating each in a
>       set of Flow Records.
> 
> 4.3.5. Modification Function
> 
> 
>    The Modification function modifies input Flow Records/Packet Reports
>    without changing their granularity.  The function can add new
>    Information Elements, delete existing Information Elements, or modify
>    the value of specified Information Elements.  If the function
>    modifies the data structure of an original Template, it also needs to
>    modify the value of the "flowKeyIndicator".
> 
>    Adding specified Information Elements
> 
>       The function obtains the value of a specified Information Element
>       and then adds it into Flow Records/Packet Reports.  There are
>       several methods to obtain the value: retrieving the value from a
>       database or calculating the value based on the value of other
>       Information Elements and received traffic data.
> 
>       Applicable examples include adding derived packet property
>       parameters instead of Original Exporters.  Doing that can

remove "instead of Original Exporters"

>       compensate for traditional Exporters or probes unable to add
>       packet property parameters.  Therefore, Collectors do not need to
>       recognize the difference among implementations of routers from
>       several vendors or among Exporter types, such as router, switch,
>       or probe.  Typical derived packet property parameters include the
>       following.
> 
>       *  The "bgpNextHop{IPv4|IPv6}Address" described in [RFC5102]
>          indicates the egress router of a network domain.  That is
>          useful for making a traffic matrix that covers the whole
>          network domain.
> 
>       *  The BGP Community value indicates the same group of destination
>          or source IP addresses.
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 15]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
>       *  The "mplsVpnRouteDistinguisher" described in [RFC5102], which
>          cannot be extracted from the core router in MPLS networks,
>          indicates the VPN customer's identification.  Network operators
>          can monitor the traffic behavior of each customer by adding
>          "mplsVpnRouteDistinguisher" to Flow Records/Packet Reports.
> 
>    Deleting specified Information Elements
> 
>       This function deletes existing Information Elements according to
>       instruction rules, which indicate whether an Information Element
>       should be removed.
> 
>       Applicable examples include hiding network topology information
>       and private information.  In the case of IPFIX exporting across
>       domains, the function can avoid making a vulnerability by deleting
>       unnecessary Information Elements.  Examples of network topology
>       information include "ipNextHopIP{v4|v6}Address", "bgpNextHopIP{v4|
>       v6}Address", and "bgp{Next|Prev}AdjacentAsNumber", described in
>       [RFC5102].  In addition, MPLS-related Information Elements, such
>       as "mplsLabelStackSection", are useless for customers in the case
>       of feeding Flow Records/Packet Reports to VPN customers.
> 
>    Modifying the value of specified Information Elements
> 
>       This function modifies the value of specified Information
>       Elements.
> 
>       Applicable examples include anonymizing customers' private
>       information, such as IP address and port number, according to a
>       privacy protection policy.  Several annonymization techniques are
>       described in [I-D.boschi-ipfix-anon].  The function also reports
>       anonymization methods and part of anonymized data as subsidiary
>       information.
> 
> 4.4. IPFIX File Writer/Reader
> 
> 
>    The IPFIX File Writer stores input Flow Records/Packet Reports from
>    any process in a storage system.  If received Flow Records/Packet

It's a "file system".

>    Reports include uninteresting Information Elements, the Modification
>    Function can delete these elements before the IPFIX File Writer
>    handles them.  Therefore, IPFIX File Writers can accept input from
>    any process.  In either case, input needs to include the IPFIX header

Remove the whole sentence "Therefore,..."

>    information and the Transport Session Information along with Flow
>    Records/Packet Reports.

Why does the File Writer require header information and transport
session information as input?
We should not specify additional restrictions for the File Writer here.
Also, there are cases where there are no headers and no transport
sessions, e.g. if the writer is linked to a Metering Process.

> 
>    In contrast, the IPFIX File Reader retrieves stored Flow Records/
>    Packet Reports when operators want to retrieve past Flow Records/
>    Packet Reports on the basis of a given time period.  If the data
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 16]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
>    structure of output Flow Records/Packet Reports from the IPFIX File
>    Reader is different from what operators want, the Modification
>    function can modify the data structure.  Therefore, the output of
>    IPFIX File Readers can be input to any components.  The IPFIX File
>    Writer/Reader are described in [I-D.ietf-ipfix-file] in detail.
> 
>    The figure shows the IPFIX component model with IPFIX File Writer/
>    Reader.  IPFIX File Writer/Reader are located in the same position of
>    Exporting Process/Collecting Process, respectively.

According to ipfix-file, IPFIX File Writer/Reader operate as EP/CP. So,
"located in the same position of EP/CP" is not precise language because
writer/reader are specific types of EPs and CPs.

> 
>            IPFIX (Flow Records/Packet Reports)
>                              ^
>                            ^ |
>     .----------------------|-+--------------------.
>    .-----------------------+---------------------.|
>    | Exporting Process (es) / IPFIX File Writer  |'
>    '----^------------------^---------------------'
>         |                  | |
>         |    .-------------|-+--------------------.
>         |   .--------------+---------------------.|
>         |   |     Intermediate Process (es)      |'
>         |   '--------------^-^-------------------'
>         |                  | |
>     .---+------------------|-+--------------------.
>    .-----------------------+---------------------.|
>    | Collecting Process (es) / IPFIX File Reader |'
>    '-----------------------^---------------------'
>                            |
>             IPFIX (Flow Records/Packet Reports)
> 
> 
>    Figure E: IPFIX Mediator Component Model with IPFIX File Writer/
>    Reader.
> 
> 4.5. Flow Expiration
> 
> 
>    The Aggregation function needs expiration conditions to export cached
>    Flow Records.  These conditions are described in
>    [I-D.ietf-ipfix-architecture].  In the case of IPFIX Mediation, these
>    conditions are as follows:
> 
>    o  If there are no input/received Flow Records/Packet Reports
>       belonging to a cached Flow for a certain time period, aggregated
>       Flow Records will expire.  This time period should be configurable
>       at the Intermediate Process.
> 
>    o  If the IPFIX Mediator experiences resource constraints, aggregated
>       Flow Records may prematurely expire (e.g., lack of memory to store
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 17]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
>       Flow Records).
> 
>    o  For long-running Flows, the Intermediate Process should expire the
>       Flow on a regular basis or based on some expiration policy.  This
>       periodicity or expiration policy should be configurable at the
>       Intermediate Process.
> 
>    The Correlation function also needs similar expiration conditions.
>    However, when cached Flow Records/Packet Reports prematurely expire
>    and the function can not compute the correlation among them, cached
>    Flow Records/Packet reports may be discarded.
> 
> 4.6. Information Model
> 
> 
>    IPFIX Mediation reuse the general information model from [RFC5101]
>    and from [I-D.ietf-psamp-info].  The following new Information
>    Elements for IPFIX Mediation are also needed.
> 
>    +-----+---------------------------+-----+---------------------------+
>    |  ID | Name                      |  ID | Name                      |
>    +-----+---------------------------+-----+---------------------------+
>    | XXX | averageBitRate            | XXX | averagePacketsRate        |
>    | XXX | minimumBitRate            | XXX | minimumPacketsRate        |
>    | XXX | maximumBitRate            | XXX | maximumPacketsRate        |
>    +-----+---------------------------+-----+---------------------------+

I'm not sure if we should start exporting "rate" IEs. Rates do not
represent stable metrics. It's always better to measure "counts". So, I
suggest to have maximumPacketDeltaCount instead of maximumPacketsRate etc.

I do not understand why average rate is needed. You easily get the
average rate by dividing the delta count of the entire measurement
interval by the interval length.

> 
> 4.7. Examples
> 
> 
>    As example, in case of Intermediate Processes having different
>    functions, a Collecting Process/IPFIX File Reader replicates Flow
>    Records/Packet Reports, if necessary, and forwards them to a suitable
>    Intermediate Process/Exporting Process.  Example figure is shown
>    below.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 18]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
>                         IPFIX           IPFIX               IPFIX
>                           ^               ^                   ^
>                           |               |                   |
>     .------------.  .-----+-------. .-----+-------.    .------+------.
>     | IPFIX File |  | Exporting   | | Exporting   |    | Exporting   |
>     |  Writer    |  |  Process {i}| |  Process {j}|....|  Process {n}|
>     '-----^-^----'  '-----^-------' '-----^-------'    '------^------'
>           | |             |               |                   |
>           | +-------------+               |             Flow Records
>           |          Flow Records / Packet Reports            |
>           |        .------+-------. .-----+--------.   .------+-------.
>           |        | Intermediate | | Intermediate |   | Intermediate |
>           |        |  Process {l} | |  Process {m} |   |  Process {p} |
>           |        |              | |              |...|              |
>           |        |  Flow-based  | |  Flow-based  |   |              |
>           |        |   Collector  | |   Collector  |   |              |
>           |        |   Selection  | |   Selection  |   |              |
>      Flow Records  |      ^       | |      ^       |   |              |
>           |        |      |       | |      |       |   |              |
>           |        |  Correlation | |  Modification|   |  Modification|
>           |        |      ^       | |      ^       |   |      ^       |
>           |        |      |       | |      |       |   |      |       |
>           |        |  Selection   | |  Aggregation |...|  Selection   |
>           |        |      ^       | |     ^ ^      |   |      ^       |
>           |        '------|-------' '-----|-|------'   '------|-------'
>           |               |               | |                 |
>           |               +---------------+ |           Flow Records
>           |               |                 |                 |
>           |          Flow Records / Packet Reports            |
>    .------+------. .------+------.   .------+------.    .-----+------.
>    | Collecting  | | Collecting  |   | Collecting  |    | IPFIX File |
>    |  Process {i}| |  Process {j}|...|  Process {n}|    |  Reader    |
>    '------^------' '------^------'   '------^------'    '------------'
>           |               |                 |
>         IPFIX           IPFIX             IPFIX
> 
>    Figure F: Functional Block Examples for IPFIX Mediator.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 19]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
> 5. Security Considerations
> 
> 
>    IPFIX Mediators use the IPFIX protocol.  Security considerations
>    about Flow Records are described in [RFC5101].
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 20]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
> 6. IANA Considerations
> 
> 
>    This document has no actions for IANA.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 21]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
> 7. References
> 
> 
> 7.1. Normative References
> 
> 
>    [I-D.ietf-ipfix-architecture]
>               Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
>               "Architecture for IP Flow Information Export",
>               draft-ietf-I-D.ietf-ipfix-architectureitecture-12.txt(work
>               in progress) , September 2006.
> 
>    [I-D.ietf-psamp-framework]
>               Duffield, N., "A Framework for Packet Selection and
>               Reporting", draft-ietf-psamp-framework-13.txt , June 2008.
> 
>    [I-D.ietf-psamp-info]
>               Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
>               Carle, "Information Model for Packet Sampling Exports",
>               draft-ietf-psamp-info-11.txt (work in progress) ,
>               October 2008.
> 
>    [I-D.ietf-psamp-protocol]
>               Claise, B., Quittek, J., and A. Johnson, "Packet Sampling
>               (PSAMP) Protocol Specifications",
>               draft-ietf-psamp-protocol-09.txt , December 2007.
> 
>    [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
>               "Requirements for IP Flow Information Export(IPFIX)",
>               October 2004.
> 
>    [RFC5101]  Claise, B., "Specification of the IP Flow Information
>               Export (IPFIX) Protocol for the Exchange of IP Traffic
>               Flow Information", January 2008.
> 
>    [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
>               Meyer, "Information Model for IP Flow Information Export",
>               January 2008.
> 
> 7.2. Informative References
> 
> 
>    [I-D.boschi-ipfix-anon]
>               Boschi, E. and B. Trammell, "IP Flow Anonymisation
>               Support", draft-boschi-ipfix-anon-01.txt (work in
>               progress) , July 2008.
> 
>    [I-D.dressler-ipfix-aggregation]
>               Dressler, F., Sommer, C., Munz, G., and A. Kobayashi,
>               "IPFIX Aggregation",
>               draft-dressler-ipfix-aggregation-05.txt (work in
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 22]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
>               progress) , July 2008.
> 
>    [I-D.ietf-ipfix-file]
>               Trammell, B., Boschi, E., Mark, L., Zseby, T., and A.
>               Wagner, "An IPFIX-Based File Format",
>               draft-ietf-ipfix-file-03.txt(work in progress) ,
>               October 2008.
> 
>    [I-D.ietf-ipfix-mediator-ps]
>               Kobayashi, A., Nishida, H., Sommer, C., Dressler, F.,
>               Stephan, E., and B. Claise, "IPFIX Mediation: Problem
>               Statement",
>               draft-ietf-ipfix-mediation-problem-statement-01.txt(work
>               in progress) , September 2008.
> 
>    [I-D.peluso-flowselection]
>               Peluso, L., Zseby, T., D'Antonio, S., and M. Molina, "Flow
>               selection Techniques",
>               draft-peluso-flowselection-tech-01.txt(work in progress) ,
>               November 2007.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 23]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
> Appendix A. Acknowledgements
> 
> 
>    The authors gratefully acknowledge the contributions of
> 
>    Keisuke Ishibashi,
>    Tsuyoshi Kondoh, and
>    Daisuke Matsubara.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 24]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
> Authors' Addresses
> 
>    Atsushi Kobayashi
>    NTT Information Sharing Platform Laboratories
>    3-9-11 Midori-cho
>    Musashino-shi, Tokyo  180-8585
>    Japan
> 
>    Phone: [phone]
>    Email: [e-mail]
> 
> 
>    Haruhiko Nishida
>    NTT Information Sharing Platform Laboratories
>    3-9-11 Midori-cho
>    Musashino-shi, Tokyo  180-8585
>    Japan
> 
>    Phone: [phone]
>    Email: [e-mail]
> 
> 
>    Benoit Claise
>    Cisco Systems
>    De Kleetlaan 6a b1
>    Diegem  1831
>    Belgium
> 
>    Phone: [phone]
>    Email: [e-mail]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 25]
> 
>  
> Internet-Draft          IPFIX Mediation Framework          November 2008
> 
> 
> Full Copyright Statement
> 
>    Copyright (C) The IETF Trust (2008).
> 
>    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
>    [e-mail].
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kobayashi, et al.          Expires May 8, 2009                 [Page 26]

_______________________________________________
IPFIX mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipfix