Subject: Re: [IPFIX] WGLC comments on draft-ietf-ipfix-configuration-model-04

From: Atsushi Kobayashi <[email-masked]>
Date: Mon, 18 Jan 2010 01:26:54 +0900

Hi Gerhard,

Sorry for late reply.
Please see in-line.

> 
> >> 1.  Introduction
> >>
> >>    IPFIX and PSAMP compliant Monitoring Devices (routers, switches,
> >>    monitoring probes, Collectors etc.) offer various configuration
> >>    possibilities that allow adapting network monitoring to the goals and
> >>    purposes of the application, such as accounting and charging, traffic
> >>    analysis, performance monitoring, security monitoring.  The use of a
> >>    common vendor-independent configuration data model for IPFIX and
> >>    PSAMP compliant Monitoring Devices facilitates network management and
> >>    configuration, especially if Monitoring Devices of different
> >>    implementers and/or manufacturers are deployed simultaneously.  On
> >>    the one hand, a vendor-independent configuration data model helps
> >>    storing and managing the configuration data of Monitoring Devices in
> >>    a consistent format.  On the other hand, it can be used for local and
> >>    remote configuration of Monitoring Devices.  However, this requires
> >>    that Monitoring Devices natively support the configuration data
> >>    model, or that a mapping between the configuration data model and the
> >>    device-specific representation of configuration data is provided.
> >>
> > 
> > I want to confirm the meaning of "mapping" in last sentence.
> > If a vender deploy the different configuration model at first, does it
> > need to replace them with the common configuration data?
> 
> No.
> 
> "Mapping between the configuration data model and device-specific 
> configuration data" means that CDM parameters must correspond to 
> device-specific parameters.  If this is fulfilled, the CDM can be easily 
> converted into the device-specific data (CLI, XML, or whatever) and vice 
> versa.  On the other hand, if the device-specific parameters have a very 
> different meaning, a conversion is not possible (or at least difficult).
> 
> Side note: The conversion can be realized at different places, for example:
> - in the management system
> - on the device by running an agent
> 
> What shall we do with the last sentence "However,...."?
> Remove it?
> 

Is it better to remove the following?

"or that a mapping between the configuration data model and the
 device-specific representation of configuration data is provided."

> >>    The purpose of this document is the specification of a vendor-
> >>    independent configuration data model that covers the commonly
> >>    available configuration parameters of Selection Processes, Caches,
> >>    Exporting Processes, and Collecting Processes.  The configuration
> >>    data model is defined using UML (Unified Modeling Language) class
> >>    diagrams [UML] while the actual configuration data is encoded in
> >>    Extensible Markup Language (XML) [W3C.REC-xml-20040204].  An XML
> >>    document conforming to the configuration data model contains the
> >>    configuration data of one Monitoring Device.  In order to ensure
> >>    compatibility with the NETCONF protocol [RFC4741], YANG
> >>    [I-D.ietf-netmod-yang] is used as the modeling language.  If
> >>    required, the YANG specification of the configuration data model can
> >>    be converted into XML Schema language [W3C.REC-xmlschema-0-20041028]
> >>    using the pyang tool [YANG-WEB].  YANG provides mechanisms to adapt
> >>    the configuration data model to device-specific constraints and to
> >>    augment the model with additional device-specific or vendor-specific
> >>    parameters.
> >>
> >>    For the configuration of remote Monitoring Devices, an appropriate
> >>    protocol is needed to transfer the XML encoded configuration data.
> >>    The configuration data model is compatible with the NETCONF protocol
> >>    [RFC4741].  However, alternative protocols, such as the Simple Object
> >>    Access Protocol (SOAP) [W3C.REC-soap12-part1-20070427], are also
> >>    suitable for transferring XML data from a network management system
> >>    to a Monitoring Device.
> >>
> 
> [snip]
> 
> >> 2.  Terminology
> 
> [snip]
> 
> >>    In addition to the existing IPFIX and PSAMP terminology, the
> >>    following terms are defined:
> >>
> >>    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.
> > 
> > In the case of PSAMP Packet Reports, how is the Cache used in Metering
> > Process? Is a PSAMP Packet Report maintained in Cache until deriving
> > further properties? It seems an implementation matter.
> 
> The only difference between a PSAMP Packet Report and an IPFIX Flow 
> Record is that the Packet Report always carries information about a 
> single packet while the Flow Record may contain information about 
> multiple packets.
> 
> The CDM always includes a Cache as part of the Metering Process, even if 
> Packet Reports are generated, because this is the place where the fields 
> contained in the record are defined.  The Cache Mode specifies the 
> expiration policy and thus whether one or multiple packets are included 
> in a record.
> 
> Is there a need to clarify the definition of Cache?
> 
Yes.

In the case of Packet Reports, the current Cache definition does not
clarify what functions Cache has.

> >>    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.
> >>
> >>    Monitoring Device:  A Monitoring Device implements at least one of
> >>       the functional blocks specified in the context of IPFIX or PSAMP.
> >>       In particular, the term Monitoring Device encompasses Exporters,
> >>       Collectors, IPFIX Devices, and PSAMP Devices.
> >>
> >>    Selected Packet Stream:  The Selected Packet Stream is the set of all
> >>       packets selected by a Selection Process.
> >>
> >>
> >> 3.  Structure of the Configuration Data Model
> >>
> >>    The IPFIX reference model in [RFC5470] describes Metering Processes,
> >>    Exporting Processes, and Collecting Processes as functional blocks of
> >>    IPFIX Devices.  The PSAMP framework [RFC5474] provides the
> >>    corresponding information for PSAMP Devices and introduces Selection
> >>    Processes as functional blocks within Metering Processes.  In
> >>    Section 2 of the document, the Cache is defined as another functional
> >>    block within Metering Processes.  Further explanations about the
> >>    relationship between Selection Processes and Caches are given later
> >>    on in this section.  IPFIX File Reader and File Writer are defined as
> >>    specific kinds of Exporting and Collecting Processes in
> >>    [I-D.ietf-ipfix-file].
> >>
> >>    Monitoring Device implementations usually maintain the separation of
> >>    various functional blocks although they do not necessarily implement
> >>    all of them.  Furthermore, they provide various configuration
> >>    possibilities; some of them are specified as mandatory by the IPFIX
> >>    protocol [RFC5101] or PSAMP protocol [RFC5476].  The configuration
> >>    data model enables the setting of commonly available configuration
> >>    parameters for Selection Processes, Caches, Exporting Processes, and
> >>    Collecting Processes.  In addition, it allows specifying the
> >>    composition of functional blocks within a Monitoring Device
> >>    configuration and their linkage with Observation Points.
> >>
> >>    In a Monitoring Device implementation, the functionality of the
> >>    Metering Process is commonly split into packet Sampling and Filtering
> >>    functions performed by Selection Processes, and the maintenance of
> >>    Flow Records and Packet Reports performed by Caches.  Figure 1
> >>    illustrates this separation with the example of a basic Metering
> >>    Process consisting of one Selection Process and one Cache.
> >>
> >>                +-----------------------------------+
> >>                | 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.
> >>
> > 
> > Observed packets at different Observation Domain can be input into different
> > Metering Process. Thus, they can not enter the same Metering Process.
> > I think that the above sentence is already clear in existing IPFIX
> > documents. Or it means other something?
> 
> The whole paragraph will removed in the next version of the draft.
> 
> We had a discussion about this issue in the context of IPFIX MIB.  In 
> fact, there is no IPFIX document which says that packets observed at 
> different ODs must not enter the same MP.  Therefore, we did not add any 
> additional restriction on this in the IPFIX MIB, and we do not want to 
> do this here, either.
> 

No IPFIX documents said that?

> For clarification, I propose to add one sentence to the preceding paragraph:
> 
> NEW:
>     ... 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 Observed Packet Stream at the input of a Selection
>     Process is composed of packets from a single Observation Point. ...
> 
> Is this ok?

Fined.

> >>    Beyond the basic Metering Process shown in Figure 1, the
> >>    configuration data model enables the specification of more complex
> >>    configurations.  A single Cache may process the output of multiple
> >>    Selection Processes.  The Selected Packet Stream may be copied to
> > 
> > I cannot image that a single cache process the output from multiple Selection
> > Process. This sentence seems cause the inconsistency to the
> > definition of Observation Domain, when a Metering Process consisting of
> > a sequence of Selection Processes and Cahce.
> 
> I do not understand your point.  If there is any inconsistency, please 
> explain it to me.
> 

When a single cache processes the input from multiple Selection Processes,
it is not clear what components compose a single Metering Process.

Observed
Packet    ----> Selection Process#1 -+
Stream                               |
                                     +----> Cache#1 --->
Observed                             |
Packet    ----> Selection Process#2 -+
Stream                               
                                     
If you mean SP#1, SP#2, and Cahce#1 compose Metering Process#1, Observed
packets at different Observation Domains can enter the same Metering
Process.

Or you mean SP#1 and Cahce#1 compose Metering Process#1, and SP#2 and
Cache#1 compose Metering Process#2?

On the other hand, in the following case, SP#1, Cache#1 and Cache#2
compose MP#1, or SP#1 and Cache#1 compose MP#1 and SP#1 and Cache#2
compose MP#2?

Observed
Packet    ----> Selection Process#1 -+----> Cache#1 ---> Flow
Stream                               |
                                     +----> Cache#2 ---> Packet

Could you clarify which components compose a single MP in complicated
cases?

> > And I have another question. Are Selection Processes after Cahce
> > available as an IPFIX Mediation? 
> 
> No.  This RFC will not cover IPFPIX Mediation.
> 
Ok.

Have you already mentioned somewhere that the output of a Cache can not
be input of another Selection Process and Cache?

> >>    enter several Caches, for example one Cache that generates Flow
> >>    Records and another Cache that generates Packet Reports.  Selection
> >>    Processes can also be cascaded, such that the Selected Packet Stream
> >>    at the output of one Selection Process is passed to another Selection
> >>    Process.  Cascading Selection Processes can be useful in specific
> >>    contexts such as the example in Section 7.3.
> >>
> >>    The selection of parameters in the configuration data model is based
> >>    on configuration issues discussed in the IPFIX and PSAMP documents
> >>    [RFC3917], [RFC5101], [RFC5470], [RFC5476], [RFC5474], and [RFC5475].
> >>    Furthermore, the structure and content of the IPFIX MIB module
> >>    [I-D.ietf-ipfix-mib] and the PSAMP MIB module [I-D.ietf-psamp-mib]
> >>    have been taken into consideration.  Consistency between the
> >>    configuration data model and the IPFIX and PSAMP MIB modules is an
> >>    intended goal.  Therefore, parameters in the configuration data model
> >>    are named according to corresponding managed objects.  Certain IPFIX
> >>    MIB objects containing state data have been adopted as state
> >>    parameters in the configuration data model.  State parameters cannot
> >>    be configured, yet their values can be queried from the Monitoring
> >>    Device.
> > 
> > They can be queried from other devices as well as Monitoring Device.
> 
> I do not understand.  Why shall a Monitoring Device query state 
> information from another Monitoring Device?

I would like to say that generally other device(NMS or etc) as well as
Monitoring Device can query state parameters.

I am not sure why you limits only Monitoring Device on this. 
But, it is minor question.

> 
> >>    The next section explains how UML class diagrams are deployed to
> >>    illustrate the structure of the configuration data model.
> >>    Thereafter, Section 3.2 and Section 3.3 explain the class diagrams
> >>    for the configuration of Exporters and Collectors, respectively.
> >>    Each of the presented classes contains specific configuration
> >>    parameters which are specified in Section 4.  The formal definition
> >>    of the configuration data model in YANG is given in Section 6.
> >>    Section 7 illustrates the usage of the model with example
> >>    configurations in XML.  Section 5 gives a short introduction to YANG
> >>    concepts that allow adapting the configuration data model to the
> >>    capabilities of a device.
> >>

[snip]

> >> 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.
> >>       Therefore, a SelectionProcess object MAY be referred to from
> >>       multiple ObservationPoint objects.  The corresponding Observation
> >>       Points must belong to the same Observation Domain.
> > 
> > The Selection Process after Cache handles the Flow Records or Packet
> > Reports, not packets.
> 
> All Selection Process are located in front of a Cache, not behind.
> 

Ok, please put above sentense in this document somewhere.

> > 
> >>       A Selection Process MAY pass the Selected Packet Stream to one or
> >>       multiple Caches.  Therefore, the SelectionProcess class enables
> >>       references to objects of the Cache class.
> >>
> >>       It is possible to cascade different Selection Processes.  In this
> >>       case, the Selected Packet Stream at the output of one or multiple
> >>       Selection Processes is passed to the input of another Selection
> >>       Process.  Therefore, a SelectionProcess object MAY be referred to
> >>       from multiple SelectionProcess objects.  For the same reason, one
> >>       SelectionProcess object may refer to other objects of the same
> >>       class.  When cascading multiple Selection Processes, it must be
> >>       ensured that all packets entering a Selection Process have been
> >>       observed at Observation Points belonging to the same Observation
> >>       Domain.  A configuration example is given later in Section 7.3.
> >>
> >>       If a Selection Process is configured without any reference to
> >>       Selection Processes or Caches that receive the selected packets,
> >>       the selected packets are not accounted in any Packet Report or
> >>       Flow Record.
> 
> 
> NEW:
> 
>     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 an Observation Point.  Therefore, a
>        SelectionProcess object MAY be referred to from a single
>        ObservationPoint object.
> 
Ok, it avoid to add the restriction.

>        It is possible to cascade different Selection Processes.  In this
>        case, the Selected Packet Stream at the output of a Selection
>        Process is passed to the input of another Selection Process.
>        Therefore, one SelectionProcess object may refer to other objects
>        of the same class.  A configuration example is given below in
>        Section 7.3.
> 
>        A Selection Process MAY pass the Selected Packet Stream to one or
>        multiple Caches.  Therefore, the SelectionProcess class enables
>        references to objects of the Cache class.
> 
>        If a Selection Process is configured without any reference to
>        Selection Processes or Caches that receive the selected packets,
>        the selected packets are not accounted in any Packet Report or
>        Flow Record.
> 
> 
> 
> >>
> >>    o  The Cache class contains configuration parameters of a Cache.  A
> >>       Cache may receive the output of one or more Selection Processes
> >>       and maintains corresponding Packet Reports or Flow Records.
> >>       Therefore, an object of the Cache class MAY be referred to from
> >>       multiple SelectionProcess objects.  However, the configuration
> >>       MUST ensure that all packets entering the Selection Process have
> >                                                   ^^^^^^^^^^^^^^^^^ 
> > Cache?
> > 
> >>       been observed at Observation Points belonging to the same
> >>       Observation Domain.
> 
> This whole sentence will be removed.
> 
> >>
> >>       Configuration parameters of the Cache class specify the size of
> >>       the Cache, the Cache Mode and Layout, and expiration parameters.
> >>       The Cache Mode determines if Packet Reports or Flow Records are
> >>       generated.
> >>
> >>       A Cache MAY pass its output to one or multiple Exporting Process.
> >>       Therefore, the Cache class enables references to one or multiple
> >>       objects of the ExportingProcess class.  If a Cache object does not
> >>       specify any reference to an ExportingProcess object, the Cache
> >>       output is dropped.
> >>
> >>    o  The ExportingProcess class contains configuration parameters of an
> >>       Exporting Process.  It includes various transport protocol
> >>       specific parameters and the export destinations.  An object of the
> >>       ExportingProcess class MAY be referred to from multiple objects of
> >>       the Cache class.
> >>
> >>       An Exporting Process MAY be configured as a File Writer according
> >>       to [I-D.ietf-ipfix-file].
> >>
> >>                         +------------------+
> >>                         | ObservationPoint |
> >>                         +------------------+
> >>                              0..* |
> >>                                   |
> >>                              0..* V
> >>                         +------------------+
> >>                         | SelectionProcess |
> >>                         +------------------+<-+
> >>                              0..* |  0..* |   | 0..*
> >>                                   |       +---+
> >>                              0..* V
> >>                         +------------------+
> >>                         | Cache            |
> >>                         +------------------+
> >>                              0..* |
> >>                                   |
> >>                              0..* V
> >>                         +------------------+
> >>                         | ExportingProcess |
> >>                         +------------------+
> 
> 
> NEW:
> 
>                          +------------------+
>                          | ObservationPoint |
>                          +------------------+
>                               0..1 |
>                                    |
>                               0..* V
>                          +------------------+
>                          | SelectionProcess |
>                          +------------------+<-+
>                               0..* |  0..1 |   | 0..*
>                                    |       +---+
>                               0..* V
>                          +------------------+
>                          | Cache            |
>                          +------------------+
>                               0..* |
>                                    |
>                               0..* V
>                          +------------------+
>                          | ExportingProcess |
>                          +------------------+
> 
> 
Ok.

> >>
> >>              Figure 4: Class diagram of Exporter configuration
> >>
> 
> [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
> >>
> >>    Figure 6 shows the ObservationPoint class that identifies an
> >>    Observation Point of the Monitoring Device.  The Observation Point
> >>    can either be an interface or a linecard.
> >>
> >>    An object of the ObservationPoint class MUST specify the ID of the
> >>    Observation Domain the Observation Point belongs to.  Observation
> >>    Points that are configured with the same Observation Domain ID belong
> >>    to the same Observation Domain.
> >>
> >>    The Observation Point ID (i.e., the value of the Information Element
> >>    observationPointId [RFC5102]) is assigned by the Monitoring Device.
> >>    It appears as a state parameter in the ObservationPoint class.
> >>
> >>    The configuration parameters to identify an interface or a linecard
> >>    are as follows:
> >>
> >>    ifIndex/ifName (interface only):  Either the index or name of the
> >>       interface MUST be specified according to corresponding objects in
> >>       the IF-MIB [RFC2863].
> >>
> >>    entPhysicalIndex/entPhysicalName (linecard only):  Either the index
> >>       or name of the linecard MUST be specified according to
> >>       corresponding objects in the ENTITY-MIB [RFC4133].
> >>
> >>    direction:  This parameter specifies if ingress traffic, egress
> >>       traffic, or both ingress and egress traffic is captured, using the
> >>       values "ingress", "egress", and "both", respectively.  If not
> >>       configured, ingress and egress traffic is captured (i.e., the
> >>       default value is "both").  If not applicable (e.g., in the case of
> >>       a sniffing interface in promiscuous mode), the value of this
> >>       parameter is ignored.
> > 
> > I have one question.
> > In the case of a single ifIndex belonging to multiple Observation
> > Domains, can this Interface class be referred by multiple
> > ObservationPoint classes?
> 
> With respect to the CDM, there is no restriction.  Multiple 
> ObservationPoint objects belonging to different Observation Domain IDs
> can have the same IfIndex value.
> 

Ok.

> >>    An ObservationPoint object MAY refer to one or multiple
> >>    SelectionProcess objects configuring Selection Processes that process
> >>    the observed packets in parallel.
> >>
> >> 4.2.  SelectionProcess Class
> >>
> >>          +--------------------------------+
> >>          | SelectionProcess               |
> >>          +--------------------------------+       1..* +----------+
> >>          | name                           |<>----------| Selector |
> >>          | selectionSequenceId {readOnly} |            +----------+
> >>          |                                | 0..*
> >>          |                                |<---+
> >>          |                                |    |
> >>          |                                |----+
> >>          |                                | 0..*
> >>          |                                |
> >>          |                                | 0..*  0..* +----------+
> >>          |                                |----------->| Cache    |
> >>          +--------------------------------+            +----------+
> >>
> >>                      Figure 7: SelectionProcess class
> >>
> >>    Figure 7 shows the SelectionProcess class.  The SelectionProcess
> >>    class contains the configuration parameters of a Selection Process
> >>    which selects packets from the Observed Packet Stream at its input
> >>    and outputs the Selected Packet Stream to one or multiple other
> >>    Selection Processes or Caches.  A non-empty ordered list defines a
> >>    sequence of Selectors.  The actions defined by the Selectors are
> >>    applied to the stream of incoming packet in the specified order.
> >>
> >>    The state parameter selectionSequenceId contains the Selection
> >>    Sequence ID (i.e., the value of the Information Element
> >>    selectionSequenceId [RFC5477]) which is assigned by the Monitoring
> >>    Device.  The Selection Sequence ID MUST be unique within the
> >>    Observation Domain as required by [RFC5477].
> >>
> >>    The output of one Selection Process MAY be processed by other
> >>    Selection Processes.  Therefore, the SelectionProcess class allows
> >>    references to itself, meaning that one SelectionProcess object MAY
> >>    refer to other SelectionProcess objects.
> >>
> >>    A SelectionProcess object MAY include references to one or more
> >>    objects of the Cache class configuring Caches that receive the
> >>    Selected Packet Stream and generate corresponding Packet Reports or
> >>    Flow Records.
> > 
> > If SelectionProcess class embodies the function of Metering Process, I
> > prefer the name of MeteringProcess class instead of SelectionProcess
> > from the consistency with IPFIX-MIB.
> 
> I do not understand.  SelectonProcess class corresponds to 
> ipfixSelectionProcessTable in the IPFIX-MIB.
> 

In IPFIX-MIB, there is ipfixMeteringProcessTable related to Metering
Process. On the other hand, IPFIX-CONFIG does not have some object whose
name comes from Metering Process. Reader might look for it.

And also, as I previously mentioned, it is not clear about the relation
among MP, SP, and Cache in complicated cases.

Could you add some Metering Process object, or describe clearly the
relation?

> > 
> > 
> >> 4.2.1.  Selector Class
> >>
> >>     +--------------------------------------+
> >>     | Selector                             |
> >>     +--------------------------------------+      1 +-----------------+
> >>     | name                                 |<>------+ SelectAll/      |
> >>     | selectorId {readOnly}                |        | SampCountBased/ |
> >>     | packetsObserved {readOnly}           |        | SampTimeBased/  |
> >>     | packetsDropped {readOnly}            |        | SampRandOutOfN/ |
> >>     | selectorDiscontinuityTime {readOnly} |        | SampUniProb/    |
> >>     |                                      |        | FilterMatch/    |
> >>     |                                      |        | FilterHash/     |
> >>     +--------------------------------------+        +-----------------+
> >>
> >>                          Figure 8: Selector class
> >>
> >>    The Selector class in Figure 8 contains the configuration and state
> >>    parameters of a Selector.  Standardized PSAMP Sampling and Filtering
> >>    methods are described in [RFC5475]; their configuration parameters
> >>    are specified in corresponding sampler (SampCountBased,
> >>    SampTimeBased, SampRandOutOfN, SampUniProb) or filter (FilterMatch,
> >>    FilterHash) classes.  In addition, the SelectAll class, which has no
> >>    parameters, is used for a Selector that selects all packets.  The
> >>    Selector class includes exactly one of these sampler and filter
> >>    classes, depending on the applied method.
> >>
> >>    The state parameter selectorId contains the Selector ID (i.e., the
> >>    value of the Information Element selectorId [RFC5477]) assigned by
> >>    the Monitoring Device.  The Selector ID MUST be unique within the
> >>    Observation Domain as required by [RFC5477].
> >>
> >>    As state parameters, the Selector class contains the Selector
> >>    statistics packetsObserved and packetsDropped that correspond to the
> >>    objects of the ipfixSelectorStatsTable in the IPFIX MIB module
> >>    [I-D.ietf-ipfix-mib].
> >>
> 
> [snip]
> 
> >> 4.2.3.  Filter Classes
> >>
> >>            +--------------------------+
> >>            | FilterMatch              |
> >>            +--------------------------+
> >>            | ieId/ieName              |
> >>            | ieEnterpriseNumber[0..1] |
> >>            | value                    |
> >>            +--------------------------+
> >>
> >>            +--------------------------+
> >>            | FilterHash               |
> >>            +--------------------------+    1..* +---------------+
> >>            | hashFunction = BOB       |<>-------| SelectedRange |
> >>            | ipPayloadOffset = 0      |         +---------------+
> >>            | ipPayloadSize = 8        |         | name          |
> >>            | digestOutput = false     |         | min           |
> >>            | initialiserValue[0..1]   |         | max           |
> >>            +--------------------------+         +---------------+
> >>
> >>                          Figure 10: Filter classes
> >>
> >>    The Filter classes in Figure 10 contain the configuration parameters
> >>    of specific Filtering methods.  For property match filtering, the
> >>    configuration parameters are:
> >>
> >>    ieId, ieName, ieEnterpriseNumber:  The property to be matched is
> >>       specified by either ieId or ieName, specifying the ID or name of
> >>       the Information Element, respectively. 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.
> >>
> >>    value:  Matching value.
> >>
> > 
> > Can the ranges of value be defined like hash value?
> 
> No.  The reason is that min/max fields are not specified in the Selector 
> Report Interpretation:
> http://tools.ietf.org/html/rfc5476#section-6.5.2.5
> 
> In the case of FilterHash, we do min/max fields in the Selector Report 
> Interpretation:
> http://tools.ietf.org/html/rfc5476#section-6.5.2.6
> 
> > And, I would like to specify its instruction, "match" or "unmatch".
> 
> This is not specified in the Selector Report Interpretation. Therefore, 
> we cannot allow configuring this.
> 

Above all, they apparently would be required from viewpoint of usability.

Please see http://tools.ietf.org/html/rfc5475#section-6.1 that described
it as an extension of the basic model.

Implementor will add above functions because only exact match is too
poor. In that case, can IPFIX-CONFIG expand to add these functions? 
How does it expand?

> >>    For hash-based filtering, the configuration parameters are:
> >>
> >>    hashFunction:  Hash function to be used.  The following parameter
> >>       values are defined by the configuration data model:
> >>       *  BOB: BOB Hash Function as specified in [RFC5475], Appendix A.2
> >>       *  IPSX: IP Shift-XOR (IPSX) Hash Function as specified in
> >>          [RFC5475], Appendix A.1
> >>       *  CRC: CRC-32 function as specified in [RFC1141]
> >>       Default value is "BOB".
> >>
> >>    ipPayloadOffset, ipPayloadSize:  ipPayloadOffset and ipPayloadSize
> >>       configure the offset and the size of the payload section used as
> >>       input to the hash function.  Default values are 0 and 8,
> >>       respectively, corresponding to the minimum configurable values
> >>       according to [RFC5476], Section 6.2.5.6.  These parameters
> >>       correspond to the Information Elements hashIPPayloadOffset and
> >>       hashIPPayloadSize [RFC5477].
> >>
> >>    digestOutput:  digestOutput enables or disables the inclusion of the
> >>       packet digest in the resulting PSAMP Packet Report.  This requires
> >>       that the Cache Layout of the Cache generating the Packet Reports
> >>       includes a digestHashValue field.  This parameter corresponds to
> >>       the Information Element hashDigestOutput [RFC5477].
> >>
> >>    initialiserValue:  Initializer value to the hash function.  This
> >>       parameter corresponds to the Information Element
> >>       hashInitialiserValue [RFC5477].  If not configured by the user,
> >>       the monitoring device arbitrarily chooses an initializer value.
> >>
> >>    One or more ranges of matching hash values are defined by the min and
> >>    max parameters of the SelectedRange subclass.  These parameters
> >>    correspond to the Information Elements hashSelectedRangeMin and
> >>    hashSelectedRangeMax [RFC5477].
> >>
> >> 4.3.  Cache Class
> >>
> >>    +-----------------------------------+
> >>    | Cache                             |
> >>    +-----------------------------------+          1 +-------------+
> >>    | name                              |<>----------| CacheLayout |
> >>    | cacheMode                         |            +-------------+
> >>    | maxRecords {opt.}                 |
> >>    | activeTimeout {opt.}              | 0..*  0..* +------------------+
> >>    |   {except Cache Mode "immediate"} |----------->| ExportingProcess |
> >>    | inactiveTimeout {opt.}            |            +------------------+
> >>    |   {Cache Mode "timeout" only}     |
> >>    | activeFlows {readOnly}            |
> >>    | inactiveFlows {readOnly}          |
> >>    | cacheDataRecords {readOnly}       |
> >>    | cacheDiscontinuityTime {readOnly} |
> >>    +-----------------------------------+
> >>
> >>                           Figure 11: Cache class
> >>
> >>    Figure 11 shows the Cache class that contains the configuration and
> >>    state parameters of a Cache.  The configuration parameters of the
> >>    Cache class are as follows:
> >>
> >>    cacheMode:  Configures the Cache Mode.  The following parameter
> >>       values are specified by the configuration data model:
> >>       *  immediate: Data Records expire after the first packet
> >>       *  timeout: Data Records expire after active or inactive timeout
> >>       *  permanent: Data Records never expire, but are periodically
> >>          exported with interval set by the active timeout
> >>       In the case of "immediate", PSAMP Packet Reports are generated.
> >>       Otherwise, IPFIX Flow Records are generated.
> >>
> >>    maxRecords:  Maximum number of Data Records in the Cache.  If not
> >>       configured by the user, the Monitoring Device sets this parameter.
> >>
> > 
> > When a cache becomes max Records, new Flow Records can be dropped or
> > push the old one? Does it depend on the implementation matter?
> 
> There are various possibilities, such as dropping or early expiration of 
> Flows.  I do not think that we need to specify the behavior.
> 
Ok.  It is out of scope for the document. Could you please put above sentence.

> >>    activeTimeout:  This parameter configures the active timeout in
> >>       milliseconds.  It is not available for Cache Mode "immediate".
> >>       The parameter value zero indicates infinity, meaning that there is
> >>       no active timeout.  If not configured by the user, the Monitoring
> >>       Device sets this parameter.
> >>       In the case of Cache Mode "timeout", the active timeout defines
> >>       the time after which a Flow Record is expired even though packets
> >>       matching this Flow are still received by the Cache.  In the case
> >>       of Cache Mode "permanent", the active timeout defines the interval
> >>       for periodical export of Flow Records.
> > 
> > In the case of Cache Mode "timeout", the timer for active timeout is set
> > per a Flow Record. In the case of Cache Mode "permanent", the timer
> > for active timeout is set per a Cache.
> > 
> > If it is right, each meaning "active timeout" are different. Could you please
> > add some explanation.
> > 
> >>    inactiveTimeout:  This parameter configures the inactive timeout in
> >>       milliseconds.  It is not available for Cache Modes "immediate" and
> >>       "permanent".  The parameter value zero indicates infinity, meaning
> >>       that there is no inactive timeout.  If not configured by the user,
> >>       the Monitoring Device sets this parameter.
> >>       The inactive timeout defines the time after which a Flow Record is
> >>       expired if no packets matching this Flow are received by the
> >>       Cache.
> 
> NEW:
> 
>     activeTimeout:  This parameter configures the time in milliseconds
>        after which a Flow Record is expired even though packets matching
>        this Flow are still received by the Cache.  The parameter value
>        zero indicates infinity, meaning that there is no active timeout.
>        If not configured by the user, the Monitoring Device sets this
>        parameter.  This parameter is only available for Cache Mode
>        "timeout".
> 
>     inactiveTimeout:  This parameter configures the time in milliseconds
>        after which a Flow Record is expired if no packets matching this
>        Flow are received by the Cache.  The parameter value zero
>        indicates infinity, meaning that there is no inactive timeout.  If
>        not configured by the user, the Monitoring Device sets this
>        parameter.  This parameter is only available for Cache Mode
>        "timeout".
> 
>     exportInterval:  This parameter configures the interval for
>        periodical export of Flow Records in milliseconds.  If not
>        configured by the user, the Monitoring Device sets this parameter.
>        It is only available for Cache Mode "permanent".
> 
Ok, fined.

> 
> >>
> >>    An object of the Cache class includes an object of the CacheLayout
> >>    class that defines which fields are included in the Packet Reports or
> >>    Flow Records.  A Cache object MAY refer to one or multiple
> >>    ExportingProcess objects configuring different Exporting Processes.
> >>
> >>    As state parameters, the Cache class contains the Metering Process
> >>    statistics activeFlows, inactiveFlows, and cacheDataRecords that
> >>    correspond to the objects of the ipfixMeteringProcessStatsTable of
> >>    the IPFIX MIB module [I-D.ietf-ipfix-mib].
> >>
> 
> [snip]
> 
> >> 4.4.1.  Destination Class
> >>
> >>     +------------------------------------------------+
> >>     | Destination                                    |
> >>     +------------------------------------------------+
> >>     | name                                           |<>-----+
> >>     | exportMemberType = parallel                    |       | 0..1
> >>     | ipfixVersion = 10                              |       |
> >>     | transportProtocol                              |   +------------+
> >>     | destinationIpAddress                           |   | Transport- |
> >>     | destinationPort = 4739|4740                    |   | Layer-     |
> >>     | sendBufferSize {opt.}                          |   | Security   |
> >>     | rateLimit[0..1]                                |   +------------+
> >>     | localIpAddress[0..*] {SCTP only}               |
> >>     | timedReliability = 0 {SCTP only}               |
> >>     | numberOfStreams {opt.} {SCTP only}             |
> >>     | sourceIpAddress[0..1] {UDP only}               |
> >>     | templateRefreshTimeout = 600 {UDP only}        |
> >>     | optionsTemplateRefreshTimeout = 600 {UDP only} |
> >>     | templateRefreshPacket[0..1] {UDP only}         |
> >>     | optionsTemplateRefreshPacket[0..1] {UDP only}  |
> >>     +------------------------------------------------+
> >>
> >>                        Figure 14: Destination class
> >>
> >>    The Destination class shown in Figure 14 contains the configuration
> >>    parameters of one export destination (i.e., Collector) the Exporting
> >>    Process sends IPFIX Messages to.  Some of the parameters are only
> >>    applicable if a specific transport protocol (SCTP, UDP, or TCP) is
> >>    used.  The following parameters apply to all transport protocols:
> >>
> >>    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"
> >>       target, all other destinations and files must be configured as
> >>       "secondary" targets.  If "parallel" or "loadBalancing" is used,
> >>       the same type must be configured for all destinations and File
> >>       Writers of the Exporting Process.
> >>
> >>    ipfixVersion:  Version number of the IPFIX protocol used.  If
> >>       omitted, the default value is 10 (=0x000a) as specified in
> >>       [RFC5101].
> >>
> >>    transportProtocol:  One of "sctp", "udp", and "tcp".
> >>
> >>    destinationIpAddress, destinationPort:  Destination IP address and
> >>       destination port number to be used. destinationIpAddress is a
> >>       mandatory parameter.  If destinationPort is omitted, standard port
> >>       4739 (IPFIX without TLS and DTLS) or 4740 (IPFIX over TLS or DTLS)
> >>       is used.
> >>
> >>    sendBufferSize:  Size of the socket send buffer in bytes.
> >>
> >>    rateLimit:  Maximum number of bytes per second the Exporting Process
> >>       may export to the given destination as required by [RFC5476].  The
> >>       number of bytes is calculated from the lengths of the IPFIX
> >>       Messages exported.  If this parameter is not configured, no rate
> >>       limiting is performed for this destination.
> >>
> >>    The following parameters are applicable if SCTP is transport
> >>    protocol:
> >>
> >>    localIpAddress:  This optional parameter MAY appear multiple times to
> >>       specify the list of eligible local IP addresses of the SCTP
> >>       association [RFC4960].  If omitted, all locally assigned IP
> >>       addresses are used by the SCTP endpoint.
> >>
> >>    timedReliability:  Lifetime in milliseconds until an IPFIX Message
> >>       containing Data Sets only is "abandoned" due to the timed
> >>       reliability mechanism of PR-SCTP [RFC3758].  If this parameter is
> >>       set to zero, reliable SCTP transport is used.
> >>
> >>    numberOfStreams:  Number of outbound streams requested for SCTP
> >>       associations [RFC4960].  If not configured by the user, this
> >>       parameter is set by the Monitoring Device.
> >>
> >>    The following parameters are applicable if UDP is transport protocol:
> >>
> >>    sourceIpAddress:  This parameter sets the source IP address.  If this
> >>       parameter is omitted, the address assigned to the outgoing
> >>       interface is used.
> >>
> > I would like to make available in the case of TCP.
> 
> We adopted this parameter because the Cisco CLI has it for UDP.  As far 
> as I understand, it is not used to specify the outgoing interface but 
> the (forged) source address in the IP header only.
> 
No. In current network operation, source IP address is important
parameter as a indicator of exporting device(router). Operators are
often confused that a source IP address is changed when route changes
happen. Exporting device may select source address as a optimal exit points, or
arbitrarily.  Then, some collectors may fail to recognize identical
exporting device before and after route changes.

This function is necessary to avoid the confusion.

> How do you want to forge the IP address of a TCP endpoint?  It must 
> belong to the interface.
> 
> The parameter description remains unclear in the case of multiple 
> addresses assigned to a single interface.
> 
> I'm not sure what to do.
> We can remove the parameter.
> We can change to "...one of the addresses assigned to the outgoing 
> interface is used."
> We can try to find a generic solution that defines the outgoing interface.

I propose the following.

The following parameters are applicable if TCP or UDP is transport
protocol:

sourceIpAddress:  This parameter sets the source IP address. 
If this parameter is omitted, Exporter selects outgoing interface
according to routing policy, and then arbitrarily assigns the address.

> 
> >>    templateRefreshTimeout, optionsTemplateRefreshTimeout,
> >>    templateRefreshPacket, optionsTemplateRefreshPacket:  Template
> >>       refresh parameters when using UDP as transport protocol.
> >>       templateRefreshTimeout and optionsTemplateRefreshTimeout are
> >>       specified in seconds between resendings of (Options) Templates.
> >>       If omitted, the default value of 600 seconds (10 minutes) is used
> >>       [RFC5101]. templateRefreshPacket and optionsTemplateRefreshPacket
> >>       are specified in number of IPFIX Messages.  If omitted, the
> >>       (Options) Templates are only resent after timeout.
> >>
> >>    Using the TransportLayerSecurity class, transport layer security is
> >>    enabled and configured for this export destination.  If the transport
> >>    protocol is SCTP or UDP, transport layer security is realized using
> >>    DTLS.  In the case of TCP, TLS is used instead.
> >>
> 
> [snip]
> 
> >> 4.7.  Transport Session Class
> >>
> >>    +------------------------------------------------------+
> >>    | TransportSession                                     |
> >>    +------------------------------------------------------+
> >>    | exportMemberType {readOnly} {Exporting Process only} |<>----+ 0..*
> >>    | ipfixVersion {readOnly}                              |      |
> >>    | protocol {readOnly} {except File Reader/Writer}      | +----------+
> >>    | sourceAddress {readOnly} {except File Reader/Writer} | | Template |
> >>    | destinationAddress {readOnly}                        | +----------+
> >>    |                    {except File Reader/Writer}       |
> >>    | sourcePort {readOnly} {except File Reader/Writer}    |
> >>    | destinationPort {readOnly}                           |
> >>    |                 {except File Reader/Writer}          |
> >>    | sctpAssocId {readOnly} {SCTP only}                   |
> >>    | file {readOnly} {File Reader/Writer only}            |
> >>    | templateRefreshTimeout {readOnly} {UDP only}         |
> >>    | optionsTemplateRefreshTimeout {readOnly} {UDP only}  |
> >>    | templateRefreshPacket {readOnly} {UDP only}          |
> >>    | optionsTemplateRefreshPacket {readOnly} {UDP only}   |
> >>    | status {readOnly}                                    |
> >>    | rate {readOnly}                                      |
> >>    | packets {readOnly}                                   |
> >>    | bytes {readOnly}                                     |
> >>    | messages {readOnly}                                  |
> >>    | discardedMessages {readOnly}                         |
> >>    | records {readOnly}                                   |
> >>    | templates {readOnly}                                 |
> >>    | optionsTemplates {readOnly}                          |
> >>    | transportSessionDiscontinuityTime {readOnly}         |
> >>    +------------------------------------------------------+
> >>
> >>                      Figure 21: TransportSession class
> >>
> >>    The TransportSession class contains state data about Transport
> >>    Sessions originating from an Exporting Process or terminating at a
> >>    Collecting Process.  The names and semantics of the state parameters
> >>    correspond to the managed objects in the ipfixTransportSessionTable
> >>    and ipfixTransportSessionStatsTable of the IPFIX MIB module
> >>    [I-D.ietf-ipfix-mib].  Hence, if these state parameters are queried
> >>    from the Monitoring Device, the corresponding IPFIX MIB values can be
> > 
> > They can be queried from other management device.
> 
> I do not understand.  Are you confusing "queried from" with "queried by"?
> 

My question is simple.

Monitoring Device(Exporter and Collector) and other devices(NMS etc.)
can query  these state parameters.  Why do you limit only  the
Monitoring Device?

> >>    returned without any further processing.  The MIB object
> >>    ipfixTransportSessionDeviceMode is not included in the
> >>    TransportSession class because its value can be derived from the
> >>    scope in which a TransportSession object appears: exporting(1) if it
> >>    belongs to an Exporting Process, collecting(2) if it belongs to a
> >>    Collecting Process.
> >>
> >>    The state parameter exportMemberType is only available if the
> >>    TransportSession class is used within the ExportingProcess class.
> >>    exportMemberType then contains the value of the MIB object
> >>    ipfixExportMemberType of the ipfixExportTable of the IPFIX MIB
> >>    [I-D.ietf-ipfix-mib].
> >>
> > 
> > The Destination already has exportMemberType. What is relation between
> > two object between the object in Destination class and one in this class?
> 
> This is state data of a Transport Session, the other is configuration 
> data of an Exporting Process.
> 
Ok.

> >>    The TransportSession class is also used for state data of File
> >>    Readers and File Writers.  In this case, the "file" parameter
> >>    specifies the name and location of the file as URI.  To avoid
> >>    ambiguities, the parameters "protocol", "sourceAddress",
> >>    "destinationAddress", "sourcePort", "destinationPort", and
> >>    "sctpAssocId" MUST NOT appear if the parameter "file" is present.
> >>    The parameter "file" MUST NOT appear if at least one of the
> >>    parameters "protocol", "sourceAddress", "destinationAddress",
> >>    "sourcePort", "destinationPort", and "sctpAssocId" is present.  Note
> >>    that the parameter "file" is currently not included in the IPFIX MIB.
> >>
> > 
> > The above paragraph can be removed. Because you already have File
> > Reader and Writer class.
> 
> No.
> 
> All these state parameters may be interesting for File Writers/Readers:
> 
>     | status {readOnly}                                    |
>     | rate {readOnly}                                      |
>     | packets {readOnly}                                   |
>     | bytes {readOnly}                                     |
>     | messages {readOnly}                                  |
>     | discardedMessages {readOnly}                         |
>     | records {readOnly}                                   |
>     | templates {readOnly}                                 |
>     | optionsTemplates {readOnly}                          |
>     | transportSessionDiscontinuityTime {readOnly}         |
> 
> Therefore, we have a Transport Session entry for File Readers/Writers.
> 
> 
Ok.

Regards,
Atsushi

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 22 Jan 2010 18:04:56 +0100

Hi Atsushi,

Please find answers to your comments inline.

Regards,
Gerhard

Ok.

NEW:

    Cache:  The Cache is a functional block in a Metering Process which
       generates IPFIX Flow Records or PSAMP Packet Reports from a
       Selected Packet Stream, in accordance with its configuration.  If
       Flow Records are generated, the Cache performs tasks like 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.  If Packet Reports are generated, the Cache performs
       tasks like extracting packet contents and derived packet
       properties from the Selected Packet Stream, creating new records,
       and passing them as Packet Reports to the Exporting Process.

Is this ok?

> Cache#1 compose Metering Process#2?

Your example is a single Metering Process.

> Could you clarify which components compose a single MP in complicated

Again, a single Metering Process.

The text says:

    In a Monitoring Device implementation, the functionality of the
    Metering Process is commonly split into packet Sampling and Filtering
    functions performed by Selection Processes, and the maintenance of
    Flow Records and Packet Reports performed by Caches.

It talks about Caches (plural), so there is no limitation.

What do you think about adding this sentence:

    A Metering Process may be composed of multiple Selection Processes
    and multiple Caches.

> be input of another Selection Process and Cache?

The text says:

                           As defined in [RFC5476],
    Stream).

So, it should be clear that a Selection Process cannot process Flow 
Records nor Packet Reports.

Regarding the Cache, see the new definition proposed above:

    Cache:  The Cache is a functional block in a Metering Process which
       generates IPFIX Flow Records or PSAMP Packet Reports from a
       Selected Packet Stream, in accordance with its configuration.

So, it should be clear that a Cache takes a Selected Packet Stream as 
its input, not Flow Records or Packet Reports.

This is also shown in Figur 1.

> Monitoring Device can query state parameters.

Yes, NMS may query state parameters. Shall put this as an example?

                                State parameters cannot
    be configured, yet their values can be queried from the Monitoring
    Device, for example by a network management station (NMS).

> But, it is minor question.

I think that you misunderstand the phrase. It does NOT say:
"their values can be queried BY the Monitoring Device"

> Ok, please put above sentense in this document somewhere.

See comment above.

With the new term definition of Cache (which mentions Selected Packet 
Stream), I hope that this is clear now.

> among MP, SP, and Cache in complicated cases.

See my proposed changes above.

> Could you add some Metering Process object, or describe clearly the

We decided not to add any Metering Process class to the model because 
there are no parameters to configure.

Another problem is that no other object would refer to a MeteringProcess 
object. ObservationPoint objects refer to explicit SelectionProcess 
objects. That cannot be changed.

> Above all, they apparently would be required from viewpoint of usability.

I agree. But this is not the document to solve this problem.

> poor. In that case, can IPFIX-CONFIG expand to add these functions? 

The model can be extensible by vendors or in later revisions of the model.

NEW:

    maxRecords:  Maximum number of Data Records in the Cache.  If the
       Cache stores this number of Data Records, no additional record can
       be created before any of the existing records is removed.  If
       not configured by the user, the Monitoring Device sets this
       parameter.

Is this ok?

> This function is necessary to avoid the confusion.

I will ask Benoit how this parameter is used.

> according to routing policy, and then arbitrarily assigns the address.

You cannot use an arbitrary source IP address with TCP.

> can query  these state parameters.  Why do you limit only  the

It's a misunderstanding. See reply above.

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