Subject: [IPFIX] ipfix-configuration-02

From: kobayashi atsushi <[email-masked]>
Date: Wed, 22 Aug 2007 03:02:13 +0900

Hi Gerhard and all,

I have reviewed, shortly. It is interesting. I think that it is valuable
to complement for IPFIX-MIB. I have listed up my comments, as follows.

- 1. Specific issue
IMHO, Metering Process Id is necessary.
Already this topics has been discussed in another thread. If it does not
has the id, we cannot identify the following cases.

Case#1)
ObservationPoint#1 ------> MeteringProcess#1 
                           (SelectionProcess =my_sampler and my_filter)
ObservationPoint#2 ------> MeteringProcess#2
                           (SelectionProcess =my_sampler and my_filter)
Case#2)
ObservationPoint#1 ----+ 
                       +-> MeteringProcess#1
ObservationPoint#2 ----+   (SelectionProcess =my_sampler and my_filter)

I think that both cases are presented by same XML configuration. But,
the outputs of metering process are different. Especially it depends on
the sampling methods.

  <ObservationPoint>
    <observationDomainId>12345</observationDomainId>
    <Interface>
      <ifName>eth0</ifName>
    </Interface>
    <MeteringProcess>
      <SelectionProcess id="my_sampler" />
      <CacheParameters id="my_cache" />
    </MeteringProcess>

::

  <ObservationPoint>
    <observationDomainId>54321</observationDomainId>
    <Interface>
      <ifName>eth1</ifName>
    </Interface>
    <MeteringProcess>
      <SelectionProcess id="my_sampler" />
      <CacheParameters id="my_cache" />
    </MeteringProcess>

- 5.1 ObservationPoint Class
I hope that it includes the direction of observed traffic. The type of 
direction corresponds to "in", "out", "both".

- 5.3.2 Filter Class
I hope that FilterMatch can operate OR and AND. According to
"draft-ietf-psamp-sample-tech-10", it indicates that OR operations are not
supported with this basic model. But, general ACL list of routers has
both operation. IMHO, the XML data models can easily present OR and AND
operations. 

- 5.4 CacheParameters Class
If we select the "immediate" type, the IPFIX datagram might have only
one flow records. Generally, the load of router depends on the volume of
IPFIX packets. Preferably, it is better that IPFIX datagram has multiple
flow records. To mitigate it, I hope that this class has the maximum
timer until it exports them.
Even if we select "immediate", it can wait until time out, or the flow
records are filled in the IPFIX packet.

- 5.4.1 Template Class
I understood that it indicates template id can be assigned by user. I
agree it. But, it seems to become difficult to keep the unique template
id. In case of assignment by user, it seems to need to add a note of
caution. 

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

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

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 22 Aug 2007 10:26:23 +0200

Dear Kobayashi,

Thank you very much for your feedback. I'll reply to your comments inline.

kobayashi atsushi wrote:
> I think that both cases are presented by same XML configuration. 

We need to consider the cache as well:

Case#1)
ObservationPoint#1 ------> MeteringProcess#1
                           * SelectionProcess#1 = my_sampler & my_filter
                           * Cache#1
ObservationPoint#2 ------> MeteringProcess#2
                           * SelectionProcess#1 = my_sampler & my_filter
                           * Cache#2

Case#2)
ObservationPoint#1 ----+
                       +-> MeteringProcess#1
ObservationPoint#2 ----+   * SelectionProcess#1 = my_sampler & my_filter
                           * Cache#1

As you see, there is a one-to-one correspondance:
MeteringProcess#1  <=>  (SelectionProcess#1, Cache#1)
MeteringProcess#2  <=>  (SelectionProcess#1, Cache#2)

Two Metering Processes are implicitly identical, if they deploy the same
Selection Processes (in the same order/sequence) and if they make use of
the same cache.

In the configuration data model, we could give ids to the Metering
Processes and regard them as entities/instances. However, this is an
unnecessary double indexing of the same thing.

> But, the outputs of metering process are different. Especially it
depends on
>       <CacheParameters id="my_cache" />

This is how the two cases would look like:

Case 1:

<ObservationPoint>
  <observationDomainId>12345</observationDomainId>
  <Interface>
    <ifName>eth0</ifName>
  </Interface>
  <MeteringProcess>
    <SelectionProcess id="my_sampler_and_filter" />
    <CacheParameters id="my_cache_1" />
  </MeteringProcess>
</ObservationPoint>

<ObservationPoint>
  <observationDomainId>54321</observationDomainId>
  <Interface>
    <ifName>eth1</ifName>
  </Interface>
  <MeteringProcess>
    <SelectionProcess id="my_sampler_and_filter" />
    <CacheParameters id="my_cache_2" />
  </MeteringProcess>
</ObservationPoint>

<SelectionProcess id="my_sampler_and_filter">
   ...
</SelectionProcess>

<CacheParameters id="my_cache_1">
   ...
   <ExportingProcess id="my_exporter" />
</CacheParameters>

<CacheParameters id="my_cache_2">
   ...
   <ExportingProcess id="my_exporter" />
</CacheParameters>

<ExportingProcess id="my_exporter">
   ...
</ExportingProcess>

Note: Cache 1 and 2 can also be linked to different Exporting Processes.

Case 2:

<ObservationPoint>
  <observationDomainId>12345</observationDomainId>
  <Interface>
    <ifName>eth0</ifName>
  </Interface>
  <MeteringProcess>
    <SelectionProcess id="my_sampler_and_filter" />
    <CacheParameters id="my_cache" />
  </MeteringProcess>
</ObservationPoint>

<ObservationPoint>
  <observationDomainId>54321</observationDomainId>
  <Interface>
    <ifName>eth1</ifName>
  </Interface>
  <MeteringProcess>
    <SelectionProcess id="my_sampler_and_filter" />
    <CacheParameters id="my_cache" />
  </MeteringProcess>
</ObservationPoint>

<SelectionProcess id="my_sampler_and_filter">
   ...
</SelectionProcess>

<CacheParameters id="my_cache">
   ...
   <ExportingProcess id="my_exporter" />
</CacheParameters>

<ExportingProcess id="my_exporter">
   ...
</ExportingProcess>

I hope this clarifies how it works.

> direction corresponds to "in", "out", "both".

Such as parameter can be easily added to the specification. I assume we
need this for the Interface and the Linecard as well. Are you aware of
any MIB variable name that we could adopt as XML element name?

> both operation. IMHO, the XML data models can easily present OR and AND

The current filter and sampler classes correspond to what is specified
in the PSAMP-MIB which, for the moment, does not allow the description
of ORed filters.
Also this is not a very convenient solution, an OR can be achieved by
specifying two parallel SelectionSequences heading to the same cache.
This would look like this:

<ObservationPoint>
  <observationDomainId>54321</observationDomainId>
  <Interface>
    <ifName>eth1</ifName>
  </Interface>
  <MeteringProcess>
    <SelectionProcess id="my_first_filter" />
    <CacheParameters id="my_cache" />
  </MeteringProcess>
  <MeteringProcess>
    <SelectionProcess id="my_second_filter" />
    <CacheParameters id="my_cache" />
  </MeteringProcess>
</ObservationPoint>

I'm open to add more sophisticated filter options to the data model.
However, a consensus among IPFIXlers is necessary in order to make sure
that such filter configurations will be supported by
implementations/devices.

> records are filled in the IPFIX packet.

Good point. In former versions (-00,-01), I had introduced two Exporting
Process parameters:

       <ipfixPacketRestrictions>
         <maxPacketSize>1500</maxPacketSize>
         <maxExportDelay unit="msec">500</maxExportDelay>
       </ipfixPacketRestrictions>

The first specifies the maximum IPFIX message size, which can be useful
to avoid fragmentation in the case of UDP. Yet, as devices can query the
MTU autonomously, we omitted this parameter in -02.

The second parameter was to specify a maximum export delay which allows
the Exporting Process to wait for more records if the IPFIX message is
not yet filled. I think this corresponds to the timer you are referring to.
We omitted this parameter because Flexible Netflow does not allow to
configure it. In our implementation (Vermont), we do have both of these
parameters, and we would extend the configuration data model with
device-specific parameters in order to configure them.

Yet, if more people think that we need something like maxExportDelay, we
can add such a parameter in the standard configuration data model.

> id. In case of assignment by user, it seems to need to add a note of

You are right, we will add such a note in the next version.

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

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 22 Aug 2007 10:26:23 +0200

Dear Kobayashi,

Case#1)

Case#2)
ObservationPoint#1 ----+
                       +-> MeteringProcess#1

depends on

Case 1:

<ObservationPoint>

<ObservationPoint>

Case 2:

<ObservationPoint>

<ObservationPoint>

<ObservationPoint>

Regards,
Gerhard

---

From: kobayashi atsushi <[email-masked]>
Date: Fri, 24 Aug 2007 02:54:03 +0900

Dear Gerhard,

Thank you for your reply. Please see in-line.

On Wed, 22 Aug 2007 10:26:23 +0200

> unnecessary double indexing of the same thing.

In Section 5.4, your configuration draft say as follows.

   The CacheParameters class contains the configuration parameters of a
   record cache.  Each instance of the CacheParameters class is
   identified by a unique identifier, which allows deploying it in
   different Metering Processes, i.e. multiple instances of the
   MeteringProcess class can refer to it.  The configuration parameters

If the above case is identified by instance of cache class, it seems to
be strange that cache class is allowed to be located in multiple Metering
Processes. Because, just like case#2, the cache#1 is only one entity.

Anyway, above point might be misunderstood by some readers, like me. I
think that it is better to add it as configuration samples.

> that such filter configurations will be supported by

It seems that each packet is passed through different filters after
duplication. 

These filters of "Cisco NetFlow input filter" and "Juniper Firewall
filter" are general ACL list which be used to control packets.
Applying configuration model of ACL could be considered as one solution.

Surely, a consensus among IPFIXlers is necessary.

> can add such a parameter in the standard configuration data model.

I agree 2 parameters, maxPacketSize and maxExportDelay.

> Dipl.-Ing. Gerhard M〓z

---

---

From: kobayashi atsushi <[email-masked]>
Date: Fri, 24 Aug 2007 02:54:03 +0900

Dear Gerhard,

---

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 24 Aug 2007 11:01:47 +0200

Dear Kobayashi,

Please see inline.

> Processes. Because, just like case#2, the cache#1 is only one entity.

Yes, the same cache can be used in different (SelectionProcess, Cache)
combinations.
This corresponds to the common practice, e.g. in NetFlow, you can deploy
the same cache with different samplers.

> think that it is better to add it as configuration samples.

Yes, the Metering Process in the data model seems to be the reason for
some misunderstandings. However, I do not see a better solution right
now. Maybe some more explanations and examples help to make things more
comprehensive.

Regards,
Gerhard

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 24 Aug 2007 11:01:47 +0200

Dear Kobayashi,

Please see inline.

Regards,
Gerhard