Subject: Re: [IPFIX] review: draft-muenz-ipfix-configuration-04.txt

From: Gerhard Muenz <[email-masked]>
Date: Tue, 29 Apr 2008 18:21:08 +0200

Paul,

Thank you very much for your review.

I integrated your comments as far as they are clear and still applicable
to the current working document.

Let me reply inline to those comments where you asked for clarification,
where I do not agree, or where I'm not sure about the consequences:

Paul Aitken wrote:
> 2.  Introduction, 2nd paragraph:
> 
>>    The purpose of this document is the specification of a device-
>>    independent configuration data model that covers the commonly
>>    available configuration parameters of IPFIX Metering Processes, 
>                                            ^^^^^
>>    Exporting Processes, and Collecting Processes. 

> 4.  Structure of the Configuration Data Model
> 
>>    The IPFIX reference model in [I-D.ietf-ipfix-architecture] specifies
>>    the role and function of IPFIX Metering Processes, Exporting
>                               ^^^^^
>>    Processes, and Collecting Processes. In [I-D.ietf-psamp-framework],
>> the
>>    corresponding information is specified for the PSAMP architecture.
>>    IPFIX and PSAMP compliant monitoring deviFrom [email-masked]  Tue Apr 29 09:22:07 2008
Date: Tue, 29 Apr 2008 18:21:08 +0200
From: Gerhard Muenz <[email-masked]>
To: Paul Aitken <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [IPFIX] review: draft-muenz-ipfix-configuration-04.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

Paul,

Thank you very much for your review.

I integrated your comments as far as they are clear and still applicable
to the current working document.

Let me reply inline to those comments where you asked for clarification,
where I do not agree, or where I'm not sure about the consequences:

Paul Aitken wrote:
> 2.  Introduction, 2nd paragraph:
> 
>>    The purpose of this document is the specification of a device-
>>    independent configuration data model that covers the commonly
>>    available configuration parameters of IPFIX Metering Processes, 
>                                            ^^^^^
>>    Exporting Processes, and Collecting Processes. 

> 4.  Structure of the Configuration Data Model
> 
>>    The IPFIX reference model in [I-D.ietf-ipfix-architecture] specifies
>>    the role and function of IPFIX Metering Processes, Exporting
>                               ^^^^^
>>    Processes, and Collecting Processes. In [I-D.ietf-psamp-framework],
>> the
>>    corresponding information is specified for the PSAMP architecture.
>>    IPFIX and PSAMP compliant monitoring dece implementations usually
>>    maintain the separation of Metering Processes, Exporting Processes,
>>    and Collecting Processes (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].  The configuration data model enables the setting
>>    of commonly available configuration parameters for IPFIX Metering
>                                                         ^^^^^
>>    Processes, Exporting Processes, and Collecting Processes.

Why do you want to insert "IPFIX"?
The draft is about the configuration of IPFIX Devices and PSAMP Devices.

>>    In
>>    addition, it allows specifying the composition of Metering Processes,
>>    Exporting Processes, and Collecting Processes within a monitoring
>>    device configuration.
> 
> This implies that an Exporting Process and Collecting Process will exist
> within the same device?

This is possible. For example as shown in the configuration example 7.3.
EP and CP would also coexist in a concentrator/mediator.

>>    o  The Cache class contains configuration parameters of a cache which
>>       stores the Flow Records in the monitoring device.  Configuration
>                    ^^^^^^
> 
> - because RFC 5101 says "The Metering Process generates Flow Records."

PSAMP has not specified the term "Packet Record". PSAMP-PROTO says that
a packet record is just a Flow Record reporting a single packet.
So, if I wrote Flow Record all the time, would it be clear for you that
this implies such single packet PSAMP records?

> 5.1.  ObservationPoint Class
> 
>>    The ObservationPoint class identifies an Observation Point of the
>>    monitoring device, which is either an interface or a linecard. 
> 
> For "post" elements, the OP may be considered to be a process inside the
> box.
> 
> RFC 5101 says:
> 
>       An Observation Point is a location in the network where IP packets
>       can be observed.  Examples include: a line to which a probe is
>       attached, a shared medium, such as an Ethernet-based LAN, a single
>       port of a router, or a set of interfaces (physical or logical) of
>       a router.
> 
> - so some grouping of interfaces / linecards may be desirable too.

Do you propose multiple interfaces or multiple linecards in one
Observation Point?
Or even a mixture of interfaces and linecards?
Are there semantic differences compared to multiple OPs in the same
Observation Domain?

> Also, recall that IPFIX allows an OP to be composed of set of OPs:
> 
>       Note that every Observation Point is associated with an
>       Observation Domain (defined below), and that one Observation Point
>       may be a superset of several other Observation Points.

Do you propose to map this nesting of OPs into the configuration data model?
I do not see any advantages.

> 5.2.  MeteringProcess Class
> 
>>    The MeteringProcess class represents a Metering Process.  It refers
>>    to one instance of the Cache class that specifies a record cache in
>>    the monitoring device.  In addition, the MeteringProcess class may
>>    refer to one or multiple instances of the SelectionProcess class
>>    which specify sampling and filtering methods applied to the packets
>>    before entering the record cache.  The order of the Selection
>>    Processes references in the XML document corresponds to the sequence
>>    in which they are applied.  If no SelectionProcess is specified, all
>>    observed packets are selected. 
> 
> Is it possible to disable a MP? ie, to have MPs configured but inactive?
> This may be useful during configuration - so the config can be loaded,
> then activated. It may also be useful to have configs standing by - eg
> day/night monitoring, or weekday/weekend. Or normal / attack scenario.
> 
> The same is true for EP too - it may be desirable to have an EP standing
> bye, configured and ready to leap into action at a moment's notice :-)

You can specify Selection Processes, Caches, and Exporting Processes
which are not referred to from any other instance.
Thus, they do not get any input and can be regarded as standby components.
We might clarify this in the text unless you propose something else.

> 5.3.  SelectionProcess Class
> 
> The configuration parameters seems to be related to the PSAMP
> selectorAlgorithm (even if not quite 1:1?) which is an IANA-controlled
> registry. Do you envisage the configuration model encompassing additions
> to the selectorAlgorithm?

I do not envisage it, but probably the configuration data model cannot
depend on the registry.
The registry does not yet exist and I do not know if it includes a
specification of parameters for each algorithm. If this is not the case,
it is useless for us.
The parameters in the model are the same as in the PSAMP-MIB, which also
does not depend on the registry.

> 5.4.  Cache Class
>>    o  activeTimeout: timeout after which an active Flow is timed out
>>       anyway even if there is still a continuous flow of packets.
>>    o  idleTimeout: A Flow is considered to be timed out if no packets
>>       belonging to the Flow have been observed for the amount of time
>>       specified by this parameter.
> 
> In what units are these timeouts expressed? What ranges do they have?

The unit is timeticks = hundredths of a second.
This data type is provided by YANG, so I use it. I added a not to the text.

> 5.4.1.  Template Class
> 
> Is it likely (or even allowed) that a cache (and thus, the template)
> will contain enterprise specific IEs from different enterprises?
> 
> If not, then the field definition need not contain the enterpriseNumber.
> Rather, I expect this would be a property of the Monitoring Process
> (since the MP may be connected to a different vendor's EP).
> 
> Presumably the ieID would suffice to indicate that it's an
> enterprise-specific ID by having its top bit set?

Your proposal is not compatible with biflow export.

>>    o  isFlowKey: If present, this field is a Flow Key.
> 
> It may be more convenient to have a boolean - so, if present and set,
> then the field is a key field.

Hm, you think that it is it more convenient to add
<isFlowKey>TRUE</isFlowKey> or <isFlowKey>FALSE</isFlowKey>
to every field? That is much more text.

However, I could imagine that "isFlowKey" makes you think that a boolean
value is required. What do you think about changing the parameter name
to <flowKey/>?

> 5.5.2.  Export Parameters Classes
> 
>>    o  sourceIpAddress: In the case of UdpExport, this optional parameter
>>       may appear once to set the source IP address.  If this parameter
>>       is omitted, the address assigned to the outgoing interface is
>>       used.
> 
> If the exporring device is a router then it can selects the output
> interface itself, according to its own routing table. But what if it's
> not a router? How would it determine the correct outgoing interface?

I do not know. I only know that the sourceIpAddress exists in CISCO
Netflow CLI. That's why the parameter exists also in the draft. Maybe I
misinterpreted the CISCO CLI?

>>       In the case of SctpExport, 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.
> 
> Really? Even if those addresses are assigned to interfaces in different
> networks? :-o

Yes. That is called multihoming, a feature of SCTP.

>>    o  uri: file name and location encoded as URI if the measurement data
>>       is exported to a file.
> 
> So the file can be local or even remote?

I do not know what writer implementations will support. URI is a
flexible descriptor, therefore I use it here.

> 5.5.3.  Option Class
>> The Option Template can be specified manually, using the
>> OptionTemplate class.
> 
> Consider adding this as an "or, ..." at the bottom of the list.

The list is about types of information that can be exported using options.
For some of these types, it might make sense to configure the Option
Template manually. Therefore, the configuration of the Option Template
is not an additional bullet points in the list.

>> The timeout parameter specifies the reporting interval.
> 
> Consider also having a packet interval - because it may be more
> appropriate to export the option (and templates, BTW) more frequently in
> proportion to the amount of data that's exported.

What do you mean by packet?
observed packet?
IPFIX message?
Doesn't it make more sense to count records?

Are these parameters commonly supported? Otherwise, maybe
vendor-specific extensions?

> 5.6.  CollectingProcess Class and Receiver Class
> 
>>    o  ipAddress, transportPort: IP address and port number of the
>>       receiving port.  If ipAddress is omitted, the Collecting Process
>>       receives data sent to any local IP address.
> 
> If there are multiple collecting processes running in the same server,
> would/should they all receive data from the same port(s)? (ie, data
> duplication).

In our implementation, this is not possible because the socket belongs
to the CP. It's maybe different in other implementations.

Regards,
Gerhard

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

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