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

From: Atsushi Kobayashi <[email-masked]>
Date: Tue, 09 Feb 2010 01:15:02 +0900

Hi Gerhard, and all,

I find my following answer could not have been shared in list due to our
network trouble.

Regards,
atsushi

On Tue, 26 Jan 2010 10:37:23 +0900
Atsushi Kobayashi <[email-masked]> wrote:

> 
> Hi Gerhard,
> 
> Thank you for your reply. Please see in-line.
> 
> On Fri, 22 Jan 2010 18:04:56 +0100
> Gerhard Muenz <[email-masked]> wrote:
> 
> > 
> > Hi Atsushi,
> > 
> > Please find answers to your comments inline.
> > 
> > Regards,
> > Gerhard
> > 
> > 
> > 
> > Atsushi Kobayashi wrote:
> > > 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."
> > 
> > Ok.
> > 
> > >>>>    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.
> > 
> > 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?
> > 
> Fine.
> 
> > 
> > >>>>    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.
> > 
> > 
> > >>>>    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?
> > 
> > Your example is a single Metering Process.
> > 
> > > 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?
> > 
> > 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.
> 
> Ok.
> 
> > 
> > 
> > >>> 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?
> > 
> > The text says:
> > 
> >                            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).
> > 
> > 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.
> > 
> Ok.
> 
> > 
> > >>>>    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.
> > 
> > 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).
> > 
> > > I am not sure why you limits only Monitoring Device on this. 
> > > 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.
> 
> > >>>>    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.
> > 
> > See comment above.
> > 
> > With the new term definition of Cache (which mentions Selected Packet 
> > Stream), I hope that this is clear now.
> > 
> 
> Ok.
> > 
> > 
> > >>>> 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.
> > 
> > See my proposed changes above.
> > 
> 
> Ok.
> 
> > > Could you add some Metering Process object, or describe clearly the
> > > relation?
> > 
> > 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.
> > 
> > 
> > >>>> 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.
> > 
> > I agree. But this is not the document to solve this problem.
> > 
> > > 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?
> > 
> > The model can be extensible by vendors or in later revisions of the model.
> > 
> Ok, I understood what you would like to say. I am concerned that the
> extensions are built indiscriminately.
> 
> 
> > >>>>    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.
> > 
> > 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?
> > 
> Ok.
> 
> > 
> > >>>>    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.
> > 
> > I will ask Benoit how this parameter is used.
> > 
> > >> 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.
> > 
> > You cannot use an arbitrary source IP address with TCP.
> > 
> 
> I mean exporting device may select appropriate source ip
> address as TCP client along with routing policy if the parameter is
> omitted. The routing policy may change between before and after its
> shutdown or link-failure, etc. This may cause in the case of TCP.
> 
> In simple example, if you can use source IP address on loopback, it
> avoid this problem.
> 
> > >>>>    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]
> 
> Regards,
> Atsushi
> 
> --- 
> Atsushi KOBAYASHI  <[email-masked]>
> NTT Information Sharing Platform Lab.
> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637

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