Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-configuration-model-04

From: "Juergen Quittek" <[email-masked]>
Date: Thu, 18 Feb 2010 02:54:43 +0100

Dear all,

There is still just one review for this draft. Brian is working
on a second review, but I want to see at least a third one before
closing the WGLC.

Would anyone be willing to add another review for this document?

Thanks,

    Juergen

On 19.01.10 02:55  "Juergen Quittek" <[email-masked]> wrote:

> Dear all,
> 
> I received only one review of this document during WGLC.
> Did I miss any review?
> 
> I don't think a single review is enough to pass a WGLC
> successfully. 
> 
> Are there any volunteers for reviewing the draft?
> 
> Thanks,
> 
>     Juergen
> 
> 
> On 27.11.09 13:56  "Juergen Quittek" <[email-masked]> wrote:
> 
>> Dear all, 
>> 
>> At our session at Hiroshima we agreed to have working group last call
>> on draft-ietf-ipfix-configuration-model-04.
>> 
>> The call starts today and will last until Friday December 11.
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/id/draft-ietf-ipfix-configuration-model-04.txt
>> 
>> I will ask the NETMOD WG to also review the draft as soon as the
>> YANG specification is final.
>> 
>> Please read the draft!
>> Please send your comments to this mailing list!
>> Please also send a message if you are fine with the draft as it is!
>> 
>> Thank you, 
>> 
>>     Juergen 
>> _______________________________________________
>> IPFIX mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Lothar Braun <[email-masked]>
Date: Fri, 19 Feb 2010 13:12:52 +0100

Dear Juergen, all,

> Would anyone be willing to add another review for this document?

I will find some time to review the draft in the next days and should be
able to send my review to the list within the next week.

Best regards,
  Lothar

--
Lothar Braun
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18010       Fax: +49 89 289-18033
E-mail: [email-masked]

---

From: Andrew Johnson <[email-masked]>
Date: Fri, 19 Feb 2010 15:50:56 +0000

One general comment:

  Why do only some of the UML fields have settings given>
  e.g. "direction = both"

========================================================================
Section 3:
========================================================================
If a Selection Process is part of a Metering Process and a single
Selection Process can feed into more than one Cache, then it is
implied that a single Metering Process can have more than once cache.

I can see why it would be convenient to configure multiple caches to
be populated from a single Selection Process, and it could even be
implemented that way (to some extent), but that is not the PSAMP model.
The configuration model doesn't have to exactly match this model, but
you should ensure that the differences are made clear.

========================================================================
>From section 3.1:
========================================================================
Why have so many SCTP or UDP only options?  Can't you use UML
inheritance to do something like:

    +------------------------------------------------+
    | Destination                                    |
    +------------------------------------------------+
    | name                                           |
    | exportMemberType = parallel                    |
    | ipfixVersion = 10                              |
    | transportProtocol                              |
    | destinationIpAddress                           |
    | destinationPort = 4739|4740                    |
    | sendBufferSize {opt.}                          |
    | rateLimit[0..1]                                |
    +------------------------------------------------+
          ^
          | 1
     +----+-------------------+
     |                        |
     |    +------------------------------------------------+
     |    | SCTP Destination                               |
     |    +------------------------------------------------+
     |    | localIpAddress[0..*] {SCTP only}               |<>-----+	       
     |    | timedReliability = 0 {SCTP only}               |       | 0..1    
     |    | numberOfStreams {opt.} {SCTP only}             |       |	       
     |    | sourceIpAddress[0..1] {UDP only}               |   +------------+
     |    | templateRefreshTimeout = 600 {UDP only}        |   | Transport- |
     |    | optionsTemplateRefreshTimeout = 600 {UDP only} |   | Layer-     |
     |    | templateRefreshPacket[0..1] {UDP only}         |   | Security   |
     |    | optionsTemplateRefreshPacket[0..1] {UDP only}  |   +------------+
     |    +------------------------------------------------+
     |
     +---------------------+
                           |
    +------------------------------------------------+
    | UDP Destination                                |
    +------------------------------------------------+
    | sourceIpAddress[0..1] {UDP only}               |<>-----+	       
    | templateRefreshTimeout = 600 {UDP only}        |       | 0..1    
    | optionsTemplateRefreshTimeout = 600 {UDP only} |       |	       
    | templateRefreshPacket[0..1] {UDP only}         |   +------------+
    | optionsTemplateRefreshPacket[0..1] {UDP only}  |   | Transport- |
    +------------------------------------------------+   | Layer-     |
						         | Security   |
                                                         +------------+

Are there no options that are used with TCP?
Are the security parameters the same across DTLS and TLS?

========================================================================
>From section 4.1:
========================================================================
Doesn't the direction belong in the Observation Point class, not the
Interface or LC class.

========================================================================
>From Section 4.2.1
========================================================================
Why packetsDropped and not packetsSelected, when PSAMP talks about
packetsSelected in the stats it needs to export?

========================================================================
>From Section 4.3.1
========================================================================
Isn't is possible to generate a cache without any keys?
This would generate a cache with a single flow?  Do we allow this?

Would it be useful to have two lists, one for keys and one for
non-keys?

For a permanent cache, update counters should be used and for a
timeout cache the delta counters should be used.  Where is this
sort of thing enforced?

========================================================================
>From Section 4.4.1
========================================================================
   exportMemberType:  Configures the export member type that corresponds
      to the ipfixTransportSessionGroupMemberType object in
      [I-D.ietf-ipfix-mib].  The following parameter values are
      specified by the configuration data model:
      *  primary: primary target of the Exporting Process
      *  secondary: secondary target of the Exporting Process used when
         the primary target is not reachable
      *  parallel: parallel exporting to all destinations and files of
         the Exporting Process
      *  loadBalancing: load-balancing between different destinations
         and files of the Exporting Process
      "parallel" is the default value if this parameter is not
      configured.  If one destination or file is configured as "primary"

------------------------------------------------------------------------
Comments
------------------------------------------------------------------------
It's not clear to me that this parameter belongs to the Destination
class.  The number of restrictions on when you can use the various
types suggests that we could simplify things.

A Cache can pass flow records to multiple Exporting Processes, so we
don't really need a parallel option.  This would mean that each
Exporting Process is responsible for sending one complete set of
records.  i.e. one record in, one record out.  It could do that, either
using a redundancy model or with a load-balancing one.

In other words, the exportType would be an Exporting Process attribute
which would indicate whether the list of Destinations should be load-
balanced across or treated as Primary, Seondary, Tertiary, etc.

========================================================================
>From Section 4.7: TransportSession class
========================================================================
I think you want to add a timestamp for when the session came up
and when it went down (unless it's still active).

There's no association with the relevant destination.  It seems to me
that your really want this as part of each Destination or FileReader.
Specifically, I think you want to separate the Transport Session from
the File Reader stats.  Potentially there could be a one to many
relationship of Destination and Transport Sessions, each with their own
timestamp for coming up and going down.

---

From: Lothar Braun <[email-masked]>
Date: Fri, 26 Feb 2010 14:39:40 +0100

Hi all,

please find my comments inline.

Best regards,
  Lothar

> IP Flow Information Export WG                                   G. Muenz
> Internet-Draft                                               TU Muenchen
> Intended status: Standards Track                               B. Claise
> Expires: April 26, 2010                                        P. Aitken
>                                                      Cisco Systems, Inc.
>                                                         October 23, 2009
> 
> 
>               Configuration Data Model for IPFIX and PSAMP
>                <draft-ietf-ipfix-configuration-model-04>

<snip>

> 
> 2.  Terminology
> 
>    This document adopts the terminologies used in [RFC5101],
>    [I-D.ietf-ipfix-file], and [RFC5476].  As in these documents, all
>    specific terms have the first letter of a word capitalized when used
>    in this document.  The following listing indicates in which
>    references the definitions of those terms that are commonly used
>    throughout this document can be found:
> 
> 
> 
> 
> 
> 
> Muenz, et al.  draft-ietf-ipfix-configuration-model-04.txt      [Page 6]
> Internet-Draft    IPFIX/PSAMP Configuration Data Model      October 2009
> 
> 
>    o  Definitions adopted from [RFC5101]:
>       *  Collection Process
>       *  Collector
>       *  Data Record
>       *  Exporter
>       *  Flow Record
>       *  Information Element
>       *  IPFIX Device
>       *  IPFIX Message
>       *  Observation Domain
>       *  Observation Point
>       *  (Options) Template
> 
>    o  Definitions adopted from [I-D.ietf-ipfix-file]:
>       *  File Reader
>       *  File Writer
> 
>    o  Definitions adopted from [RFC5476]:
>       *  Filtering
>       *  Observed Packet Stream
>       *  Packet Report
>       *  PSAMP Device
>       *  Sampling
>       *  Selection Process
>       *  Selection Sequence
>       *  Selection Sequence Report Interpretation
>       *  Selector, Primitive Selector, Composite Selector

You might want to add the term "Flow Keys" somewhere to this lists.

>    The terms Metering Process and Exporting Process have different
>    definitions in [RFC5101] and [RFC5476].  In the scope of this
>    document, these terms are used according to the following definitions
>    which cover the deployment in both PSAMP Devices and IPFIX Devices:

<snip>

>    Cache:  The Cache is a functional block in a Metering Process which
>       maintains IPFIX Flow Records or PSAMP Packet Reports.  According
>       to [RFC5101], the maintenance of Flow Records may include creating
>       new records, updating existing ones, computing Flow statistics,
>       deriving further Flow properties, detecting Flow expiration,
>       passing Flow Records to the Exporting Process, and deleting Flow
>       Records.  The maintenance of Packet Reports covers the same set of
>       functions.
>  
>    Cache Layout:  The Cache Layout defines the superset of fields that
>       are included in the Packet Reports or Flow Records maintained by
>       the Cache.  The fields are specified by the corresponding
>       Information Elements.  In general, the largest possible subset of
>       the specified fields is derived for every Packet Report or Flow
>       Record.  More specific rules about which fields must be included
>       are given in Section 4.3.1.
> 
>    Cache Mode:  The Cache Mode specifies whether Packet Reports or Flow
>       Records are generated by the Cache.  In the case of Flow Records,
>       it also specifies the Flow expiration policy.
> 

I had some difficulties to understand the definition of the Cache. I could not understand what the packet cache does when generating PSAMP Packet Reports. It was clear after reading Section 4.3 when the Cache Modes are explained. Maybe there could be some text that explains that maintaining Packet Reports and Flow Records is the same task except that Packet Records expire after the first packet. 

Could there be an example for a Cache?

<snip>

> 
>                +-----------------------------------+
>                | Metering Process                  |
>                | +-----------+ Selected            |
>       Observed | | Selection | Packet    +-------+ |  Stream of
>       Packet  -->| Process   |---------->| Cache |--> Flow Records or
>       Stream   | +-----------+ Stream    +-------+ |  Packet Reports
>                +-----------------------------------+
> 
>      Figure 1: Selection Process and Cache forming a Metering Process
> 
>    The configuration data model adopts the separation of Selection
>    Processes and Caches in order to support the flexible configuration
>    and combination of these functional blocks.  As defined in [RFC5476],
>    the Selection Process takes the Observed Packet Stream as its input
>    and selects a subset of that stream as its output (Selected Packet
>    Stream).  The action of the Selection Process on a single packet of
>    its input is defined by a Primitive Selector or a Composite Selector.
>    The Cache generates Flow Records or Packet Reports from the Selected
>    Packet Stream, depending on the configured Cache Mode.
> 
>    The Observed Packet Stream at the input of a Selection Process MUST
>    only contain packets originating from a single Observation Domain.
>    Similarly, the Selected Packet Stream at the input of a Cache MUST
>    only contain packets originating from a single Observation Domain.
>    Packets from Observation Points belonging to different Observation
>    Domains MUST NOT enter the same Selection Process or the same Cache.

When I read this, I had the feeling that this text does poses some restriction on how I am able to configure my monitor. But it seems like this corresponds to the definition of an Observation Domain:

 Observation Domain

      An Observation Domain is the largest set of Observation Points for
      which Flow information can be aggregated by a Metering Process.
     ... 

Is there some further restriction that I miss?

> 3.2.  Exporter Configuration
> 
>    Figure 4 below shows the main classes of the configuration data model
>    which are involved in the configuration of an IPFIX or PSAMP
>    Exporter.  The role of the classes can be briefly summarized as
>    follows:
> 
>    o  The ObservationPoint class specifies an Observation Point (i.e.,
>       an interface or linecard) of the Monitoring Device at which
>       packets are captured for traffic measurements.  An object of the
>       ObservationPoint class may be associated with one or more objects
>       of the SelectionProcess class configuring Selection Processes that
>       process the observed packets in parallel.  As long as an
>       ObservationPoint object is specified without any references to
>       SelectionProcess objects, the Observation Point is not deployed
>       for traffic measurements.
> 
>    o  The SelectionProcess class contains the configuration parameters
>       of a Selection Process.  The Selection Process may be composed of
>       a single Selector or a sequence of Selectors, defining a Primitive
>       or Composite Selector, respectively.
> 
>       The Selection Process selects packets from an Observed Packet
>       Stream originating from one or multiple Observation Points.

Could you please introduce the selectAll policy of the SelectionProcess at this point?

When I read this, I was wondering why I cannot connect an Observation Point directly to a Cache, if I do not want to sample or filter packets.

<snip>

> 
> 4.1.  ObservationPoint Class
> 
>     +-------------------------------+
>     | ObservationPoint              |
>     +-------------------------------+          1 +--------------------+
>     | name                          |<>----------| Interface/Linecard |
>     | observationPointId {readOnly} |            +--------------------+
>     | observationDomainId           |
>     |                               | 0..*  0..* +--------------------+
>     |                               |----------->| SelectionProcess   |
>     +-------------------------------+            +--------------------+
> 
>     +------------------+   +----------------------------------+
>     | Interface        |   | Linecard                         |
>     +------------------+   +----------------------------------+
>     | ifIndex/ifName   |   | entPhysicalIndex/entPhysicalName |
>     | direction = both |   | direction = both                 |
>     +------------------+   +----------------------------------+
> 
>                      Figure 6: ObservationPoint class
> 

Both, the Interface and the Linecard, contain the "direction". Is there a reason why it is not a part of the Observation Point if it has to be specified in both cases?

<snip>

> 
> 
> 4.3.1.  CacheLayout Class
> 
>             +--------------+
>             | CacheLayout  |
>             +--------------+   1..* +--------------------------+
>             |              |<>------| CacheField               |
>             |              |        +--------------------------+
>             |              |        | name                     |
>             |              |        | ieId/ieName              |
>             |              |        | ieLength {opt.}          |
>             |              |        | ieEnterpriseNumber[0..1] |
>             |              |        | isFlowKey[0..1]          |
>             +--------------+        +--------------------------+
> 
>                        Figure 12: CacheLayout class
> 
>    A Cache generates and maintains Packet Reports or Flow Records
>    containing information that has been extracted from the incoming
>    stream of packets.  Using the CacheField class, the CacheLayout class
>    specifies the superset of fields that are included in the Packet
>    Reports or Flow Records (see Figure 12).
> 
>    If Packet Reports are generated (i.e., if Cache Mode is "immediate"),
>    every field specified by the Cache Layout MUST be included in the
>    resulting Packet Report unless the corresponding Information Element
>    is not applicable or cannot be derived from the content or treatment
>    of the incoming packet.

Could you give an example for "not applicable or cannot be derived from"? Maybe something like when a source port needs to be extracted from an ICMP packet.

>    If Flow Records are generated (i.e., if Cache Mode is "timeout" or
>    "permanent"), every Flow Key field specified by the Cache Layout MUST
>    be included as Flow Key in the resulting Flow Record unless the
>    corresponding Information Element is not applicable or cannot be
>    derived from the content or treatment of the incoming packet.  Two
>    packets MUST be accounted by different Flow Records if different
>    subsets of the Flow Key fields are applicable or derivable.

I do not understand this. What do you mean with "different subsets of the Flow Key fields".

Is it maybe: "Two packets MUST be accounted by different Flow Records if they differ in at least one Flow Key field."

>    ieId, ieName, ieEnterpriseNumber:  These parameters specify a field
>       by the combination of the Information Element identifier or name,
>       and the Information Element enterprise number.  Either ieId or
>       ieName MUST be specified. ieEnterpriseNumber MUST be used for
>       enterprise-specific Information Elements.  If ieEnterpriseNumber
>       is omitted or zero, this is Information Element is not enterprise-
>       specific but registered at IANA.

If I want to configure a custom non-IANA field using the Enterprise ID 1. The field should have the ieID 1. What do I have to configure. Do I need to configure ieID 1, ieEnterpriseNumber 1 or do I need to give ieID 32768 (the first bit if the id field) and ieEnterpriseNumber 1?

So my question is: Is the enterprise Bit set by the user or is it done by the monitor if he sees the ieEnterpriseNumber field?

>    ieLength:  This parameter specifies the length of the field in
>       octets.  A value of 65535 means that the field is encoded as
>       variable-length Information Element.  For Information Elements of
>       integer and float type, the field length MAY be set to a smaller
>       value than the standard length of the abstract data type if the
>       rules of reduced size encoding are fulfilled (see [RFC5101],
>       Section 6.2).  If not configured by the user, the field length is
>       set by the Monitoring Device.

The monitoring device can set the length field if it nows the ID (either IANA or known custom ID). But what if the monitor does not know a specific ID? Should there be a default value (which one?) for unknown IDs or should the device reject such a configuration?

I think the device should reject the configuration.

<snip>

> 4.4.3.  Options Class
> 
>                          +-----------------------+
>                          | Options               |
>                          +-----------------------+
>                          | name                  |
>                          | optionsType           |
>                          | optionsTimeout {opt.} |
>                          +-----------------------+
> 
>                          Figure 16: Options class
> 
>    The Options class in Figure 16 defines the type of specific
>    information to be reported, such as statistics, flow keys, Sampling
>    and Filtering parameters etc.  [RFC5101] and [RFC5476] specify
>    several types of reporting information which may be exported.  The
>    following parameter values are specified by the configuration data
>    model:
> 
>    meteringStatistics:  Export of Metering Process statistics using the
>       Metering Process Statistics Options Template [RFC5101].
> 
>    meteringReliability:  Export of Metering Process reliability
>       statistics using the Metering Process Reliability Statistics
>       Options Template [RFC5101].
> 
>    exportingReliability:  Export of Exporting Process reliability
>       statistics using the Exporting Process Reliability Statistics
>       Options Template [RFC5101].
> 
>    flowKeys:  Export of the Flow Key specification using the Flow Keys
>       Options Template [RFC5101].
> 
>    selectionSequence:  Export of Selection Sequence Report
>       Interpretation and Selector Report Interpretation [RFC5476].
> 
>    selectionStatistics:  Export of Selection Sequence Statistics Report
>       Interpretation [RFC5476].
> 
>    accuracy:  Export of Accuracy Report Interpretation [RFC5476].
> 
>    reducingRedundancy:  Export of common properties according to
>       [RFC5473].
> 
>    The Exporting Process MUST choose a template definition according to
>    the options type and available options data.

<snip>

> 7.3.  Export of Flow Records and Packet Reports
> 
>    This configuration example demonstrates the combined export of Flow
>    Records and Packet Reports for a single Observation Point.  A
>    Selection Process (Selection Sequence ID = 1) applies random Sampling
>    to the stream of observed packets.  The output is passed to a Cache
>    generating Flow Records.  In parallel, the output is passed to a
>    second Selection Process (Selection Sequence ID = 2) which discards
>    all non-ICMP packets.  A second Cache generates Packet Reports of the
>    retained ICMP packets.  The output of both caches is exported to a
>    single Collector using SCTP.
> 
>    <ipfix xmlns="urn:ietf:params:xml:ns:ietf-ipfix-psamp">
> 
>      <observationPoint>
>        <name>OP at linecard 3</name>
>        <observationDomainId>9876</observationDomainId>
>        <interface>
>          <ifIndex>4</ifIndex>
>          <direction>ingress</direction>
>        </interface>
>        <selectionProcess>Sampling</selectionProcess>
>      </observationPoint>
> 
>      <selectionProcess>
>        <name>Sampling</name>
>        <selectionSequenceId>1</selectionSequenceId>
>        <selector>
>          <name>Random sampler</name>
>          <selectorId>1</selectorId>
>          <sampUniProb>
>            <probability>0.01</probability>
>          </sampUniProb>
>        </selector>
>        <selectionProcess>ICMP</selectionProcess>
>        <cache>Flow cache</cache>
>      </selectionProcess>
> 
>      <selectionProcess>
>        <name>ICMP</name>
>        <selectionSequenceId>2</selectionSequenceId>
>        <selector>
>          <name>ICMP filter</name>
> 
> 
> 
> Muenz, et al.  draft-ietf-ipfix-configuration-model-04.txt     [Page 84]
> Internet-Draft    IPFIX/PSAMP Configuration Data Model      October 2009
> 
> 
>          <selectorId>2</selectorId>
>          <filterMatch>
>            <ieId>4</ieId>
>            <value>1</value>
>          </filterMatch>
>        </selector>
>        <cache>Packet cache</cache>
>      </selectionProcess>
> 
>      <cache>
>        <name>Flow cache</name>
>        <cacheMode>timeout</cacheMode>
>        <maxRecords>4096</maxRecords>
>        <activeTimeout>5</activeTimeout>
>        <inactiveTimeout>10</inactiveTimeout>
>        <cacheLayout>
>          <cacheField>
>            <name>Field 1</name>
>            <ieName>sourceIPv4Address</ieName>
>            <isFlowKey/>
>          </cacheField>
>          <cacheField>
>            <name>Field 2</name>
>            <ieName>destinationIPv4Address</ieName>
>            <isFlowKey/>
>          </cacheField>
>          <cacheField>
>            <name>Field 6</name>
>            <ieName>flowStartMilliSeconds</ieName>
>          </cacheField>
>          <cacheField>
>            <name>Field 7</name>
>            <ieName>flowEndSeconds</ieName>
>          </cacheField>
>          <cacheField>
>            <name>Field 8</name>
>            <ieName>octetDeltaCount</ieName>
>          </cacheField>
>          <cacheField>
>            <name>Field 9</name>
>            <ieName>packetDeltaCount</ieName>
>          </cacheField>
>        </cacheLayout>
>        <exportingProcess>Export</exportingProcess>
>      </cache>
> 
>      <cache>
>        <name>Packet cache</name>
> 
> 
> 
> Muenz, et al.  draft-ietf-ipfix-configuration-model-04.txt     [Page 85]
> Internet-Draft    IPFIX/PSAMP Configuration Data Model      October 2009
> 
> 
>        <cacheMode>immediate</cacheMode>
>        <maxRecords>512</maxRecords>
>        <cacheLayout>
>          <cacheField>
>            <name>Field 1</name>
>            <ieId>313</ieId>
>            <ieLength>64</ieLength>
>          </cacheField>
>          <cacheField>
>            <name>Field 2</name>
>            <ieId>154</ieId>
>          </cacheField>
>        </cacheLayout>
>        <exportingProcess>Export</exportingProcess>
>      </cache>
> 
>      <exportingProcess>
>        <name>Export</name>
>        <destination>
>          <name>SCTP collector</name>
>          <transportProtocol>sctp</transportProtocol>
>          <destinationIpAddress>192.0.2.1</destinationIpAddress>
>          <timedReliability>0</timedReliability>
>          <numberOfStreams>2</numberOfStreams>
>        </destination>
>      </exportingProcess>
> 
>    </ipfix>
> 
>    The Observed Packet Stream at the input of the Selection Process
>    "ICMP" originates from the Selection Process "Sampling", which thus
>    constitutes a pseudo Observation Point.  In order to inform the
>    Collector about the cascaded Selection Processes, the Exporting
>    Process exports two Selection Sequence Report Interpretations as
>    defined in [RFC5476], section 6.5.1, including the following fields:

Shouldn't there be something like

<option>
  <selectionSequence/>
</option>

in the exportingProcess configuration?

>    Selection Process "Sampling":
> 
>      Scope:      selectionSequenceId = 1
>      Non-scope:  ingressInterface = 4
>                  selectorId = 1
> 
> 
>    Selection Process "ICMP":
> 
>      Scope:      selectionSequenceId = 2
>      Non-scope:  selectionSequenceId = 1
>                  selectorId = 2
> 
> 
> 
> Muenz, et al.  draft-ietf-ipfix-configuration-model-04.txt     [Page 86]
> Internet-Draft    IPFIX/PSAMP Configuration Data Model      October 2009
> 
> 
>    One possibility to link the Selection Sequence Report Interpretation
>    of Selection Process "Sampling" to the Flow Record generated by the
>    Cache named "Flow cache" is to include a field selectionSequenceId =
>    1 to each Data Record.  Similarly, the Selection Sequence Report
>    Interpretation of Selection Process "ICMP" can be linked to the
>    Packet Reports generated by the Cache named "Packet cache" by
>    including a field selectionSequenceId = 2 to each Data Record.
> 
>    The following modifications lead to a similar but not identical
>    configuration of the Monitoring Device:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Muenz, et al.  draft-ietf-ipfix-configuration-model-04.txt     [Page 87]
> Internet-Draft    IPFIX/PSAMP Configuration Data Model      October 2009
> 
> 
>      ...
>      <observationPoint>
>        <name>OP at linecard 3</name>
>        <linecard>
>          <entPhysicalIndex>3</entPhysicalIndex>
>        </linecard>
>        <selectionProcess>Sampling</selectionProcess>
>        <selectionProcess>Sampled ICMP packets</selectionProcess>
>      </observationPoint>
>      ...
>      <selectionProcess>
>        <name>Sampling</name>
>        <selector>
>          <name>Random sampler</name>
>          <sampUniProb>
>            <probability>0.01</probability>
>          </sampUniProb>
>        </selector>
>        <cache>Flow cache</cache>
>      </selectionProcess>
> 
>      <selectionProcess>
>        <name>Sampled ICMP packets</name>
>        <selector>
>          <name>Random sampler</name>
>          <sampUniProb>
>            <probability>0.01</probability>
>          </sampUniProb>
>        </selector>
>        <selector>
>          <name>ICMP filter</name>
>          <filterMatch>
>            <ieId>4</ieId>
>            <value>1</value>
>          </filterMatch>
>        </selector>
>        <cache>Packet cache</cache>
>      </selectionProcess>
>      ...
> 
>    In this case, the random sampler is implemented in two different
>    Selection Processes, leading to different sets of selected packets.
>    As a consequence, the set of packets accounted in the Flow Cache is
>    not identical to the set of packets from which the ICMP Packet
>    Reports are generated.
> 
> 
> 
> 
> 
> 
> Muenz, et al.  draft-ietf-ipfix-configuration-model-04.txt     [Page 88]
> Internet-Draft    IPFIX/PSAMP Configuration Data Model      October 2009
> 
> 
> 7.4.  Collector and File Writer
> 
>    This configuration example configures a Collector which writes the
>    received data to a file.
> 
>    <ipfix xmlns="urn:ietf:params:xml:ns:ietf-ipfix-psamp">
> 
>      <collectingProcess>
>        <name>SCTP collector</name>
>        <receiver>
>          <name>Listening port 4739</name>
>          <transportProtocol>sctp</transportProtocol>
>          <localIpAddress>192.0.2.1</localIpAddress>
>          <localPort>4739</localPort>
>          <maxAllowedStreams>64</maxAllowedStreams>
>        </receiver>
>        <exportingProcess>File writer</exportingProcess>
>      </collectingProcess>
> 
>      <exportingProcess>
>        <name>File writer</name>
>        <fileWriter>
>          <name>Write to /tmp folder</name>
>          <exportMemberType>primary</exportMemberType>
>          <file>file://tmp/collected-records.ipfix</file>
>        </fileWriter>
>      </exportingProcess>
> 
>    </ipfix>
>