Subject: [ipfix-arch] RE: IPFIX Architecture writeup from Ram Gopal

From: <[email-masked]>
Date: Thu, 7 Feb 2002 07:59:54 -0500

Hello Ganesh,

Please see inline comments
 
>> (2)
>> G:
>> The diagram is confusing.
>> Observation Point and exporter are 2 pieces of a single 
>system and not
>> separate entities.
>> G:
>>
>> The logical functionalities are described whether u have 
>everything in one piece
>> or distributed it is upto the implementation.
>
>The point here is that IPFIX does not try to define the 
>interface between
>observation point and exporter. Showing it as 2 pieces lets 
>one think why
>the interface between these 2 should not be defined. Showing 
>the way Kevin
>Zhang has shown for the exporter part looks cleaner to me.

We are defining the IPFIX endpoint and the protocol requirement for those endpoints.
Logically exporter and collector two different components, even we had talk with Kevin 
also and merged the document into one.  I think you view from logical functional point rather
than physical view - No one wants to have  big monolithic piece.

>>
>>
>> (3)
>> G:
>> Observation point is the place where metering is done.
>> I did not understand why it is an option. Metering includes
>> filtering also.
>> From 
>http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-00.txt:
>>
>>   4. Metering Process
>>
>>      The following are requirements for the metering process. They
>>      describe the requirements for the process at the measurement
>>      instance. All measurements MUST be conducted from the 
>point of view
>>      of the observation point.
>>      .....
>> G:
>>
>> Refer requirement document 1.1 IPFlow
>>
>>    The observation point may be a network interface of a device or an
>>    entire router, a probe, or a middlebox with several interfaces.
>>    Properties derived from packet treatment include for example the
>>    interface at which the packet arrived, the interface the 
>packet will
>>    be forwarded to and potentially some other information.
>>
>> So observation point is just a probe , for example typically 
>we may have more than
>> one interface through which we would like to monitor the packet.
>
>In the above example the Observation point (the probe) is an 
>aggregation
>of interfaces. The metering is also done logically at the 
>probe level which
>gets split up into the individual interfaces depending on the 
>implementation.
>But the collector sees the observation point as the metering entity.
>I agree that metering process is not very clear in the req spec.

It is your view how you view the collector. Any architecture there will be a logical 
division of functions, Collector may know where the observation points, as far the collector
is concerned it is communicating to the exporter not to the observation points.

>> (5)
>>
>> G:
>> It is the exporter who decides what to
>> measure , where to measure & what to send. We are not defining
>> how to configure a metering process from a collector.
>> - the exporter configuration is out of the scope of this document
>> - the exporter configuration SHOULD be done out of band
>>
>> G:
>>
>> This may be one implementation, but generally exporter does 
>metering, and reporting functions and
>> more detailed in the document.
>>
>> Regarding configuration, what is said is one implementation. 
>But collector should be able to
>> request (Configure) and get the required Flow information.
>
>For this the collector needs to understand the  capability and 
>to some extent the
>implementation of an exporter and this is a non-trivial 
>problem to solve.

It is your view, there is no problem in what we described, based on the Flow you will get
the statistics or the data to the collector. I think want to put everything in one piece.

>> (6)
>>
>> G:
>>  This is already covered in the req. spec.Is there a necessity
>>  to repeat it here?
>> G:
>>
>> I think this sentence is rephrased and content of the 
>sections are different. We added more text from other authors.
>> Hope compiled version of the document will give better picture.
>
>It is better to have another doc. called applicability doc or 
>so rather than keeping
>it as a part of the architecture.

I also agree with you, but we have only two documents as defined in charter.

��ޖ���[h�f���h���z�ݢ+��+��njwlk/�zZ��y��Ơy��I칻�&ޙ�����j:+v���w���"��"���v�vƲ��칻�&ފ�������,j��܀��b��m����*_�ݢ+��+��n��܆+�

---

From: Ganesh Sadasivan <[email-masked]>
Date: Thu, 07 Feb 2002 11:35:40 -0800

Hi Ram,
   See inline
Ganesh

> than physical view - No one wants to have  big monolithic piece.

In the case of collector, you put 2 set of  boxes
[collector + App]
[collector] [App]

If you go by the arg. above it should be

[ obsv. 1..n, exporter]
[obsv 1..] [exporter].

> is concerned it is communicating to the exporter not to the observation points.

No, the point I wanted to convey is that observation point should be the logical
place where the measuring is done as seen by the collector.

> the statistics or the data to the collector. I think want to put everything in one piece.

It is a bad idea. Exporter configuration should be out of scope to the IPFIX.
Thanks
Ganesh

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/