Re: [IPFIX] ipfix-configuration-02

[kobayashi atsushi <[e-mail]>]

Dear Gerhard,

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

On Wed, 22 Aug 2007 10:26:23 +0200
Gerhard Muenz <[e-mail]> wrote:

> 
> Dear Kobayashi,
> 
> Thank you very much for your feedback. I'll reply to your comments inline.
> 
> kobayashi atsushi wrote:
> > 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. 
> 
> 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.
> 

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.

> > 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>
> 
> 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.
> 
> > - 5.1 ObservationPoint Class
> > I hope that it includes the direction of observed traffic. The type of 
> > 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?
> 
> > - 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. 
> 
> 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.

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.

> 
> > - 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.
> 
> 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.
> 

I agree 2 parameters, maxPacketSize and maxExportDelay.

> > - 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. 
> 
> You are right, we will add such a note in the next version.
> 
> Regards,
> Gerhard
> 
> -- 
> Dipl.-Ing. Gerhard M〓z
> Computer Networks and Internet
> Wilhelm Schickard Institute for Computer Science
> University of Tuebingen
> Sand 13 (Room B309), D-72076 Tuebingen, Germany
> Phone:  [phone]       Fax: [phone]
> E-mail: [e-mail]
> WWW:    http://net.informatik.uni-tuebingen.de/~muenz
> 

--- 
Atsushi KOBAYASHI  <[e-mail]>
NTT Information Sharing Platform Lab.
tel:[phone] fax:[phone]


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