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

From: <[email-masked]>
Date: Wed, 6 Feb 2002 15:41:47 -0500

Hello Ganesh,

see my line comments.

(1) 
G:
I'm not sure what can be done in connection with AAA or
other protocol here?
G:

We fixed the sentence 

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

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

My feeling is that requirement document should rectify Metering process definition.

 (4)

G:
If reliability is guaranteed by transport layer or network, this
is really not necessary. 
G:

We agree, removed this statement.

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

We are not defining what are the configuration information but we are describing 
the functionality over here.

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

 Regards
Ramg

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

---

From: Ganesh Sadasivan <[email-masked]>
Date: Wed, 06 Feb 2002 17:02:08 -0800

Hi Ram,
   See inline for my comments

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

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

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

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

Thanks
Ganesh

---

From: [email-masked]
Date: Fri, 08 Feb 2002 11:02:04 -0500

> We agree, removed this statement.

	What about application level reliability?