Subject: [ipfix-arch] Comments/questions on draft-ietf-ipfix-architecture-00.txt

From: Sebastian Zander <[email-masked]>
Date: Mon, 11 Feb 2002 13:41:02 +0100

The draft is in a very early state but nevertheless i have some comments/questions:

section 2: 

"* Describes the required mechanisms  to interoperate with other protocol/architecture 
this may includes AAA or Diameter or Intrusion Detection system.
* Identifies a minimal set of applications for IPFIX."

I don't understand why this is part of the architecture document. It's fine to list
a set of applications but describing these and the interaction with IPFIX is IMHO
out of scope of the draft.

section 3: Instead of repeating the terminology it may be sufficient to refer to the
req. draft for some of the terms (assuming that the terminology drafts includes these
as proposed by Juergen).

section 4.1:

"* In some cases, an observation point may perform metering as well."

Whats does that mean?

section 4.2:

"* Measuring, aggregating and exporting IP Flow information to the respective collectors."

The exporter does measurement?

"* May perform appropriate middle-box functions to translate the flow information." 

I would suggest deleting or rewording this to something like: May add middle-box 
information to flow record but the exporter certainly does not perform middlebox 
functions.

Am I right that the exporter does the packet to flow classification and statistics 
calculation?

section 4.3: The text totally confuses me. Why is reliability and security now a function
of the IPFIX protocol? The reqirements are already in the requirement draft and the protocol 
spec. will be in some future protocol draft I guess. Probably a wording issue which
can be solved by omitting the word protocol.

section 4.4:

Why does the collector need to maintain a repository of IP flow statistics? Can't the
application do that?

section 5:

Out of scope of this draft IMHO. There should be either an application draft or maybe
different application drafts.

section 6: I would suggest putting the requirements to the front after terminology

section 6.4: I don't understand what are here the requirements on the architecture!?
I don't think that these are architectural requirements. My understanding of this 
section is that according to certain middlebox functionality which may be done on the 
same system the exporter lives on IPFIX can provide specific information. I suggest to 
move that section at least a separate section "Architecture Considerations". Furthermore 
I think that it does *not* belong into the draft to define what information are 
exported based on some middlebox functionality. Maybe this sectio even could go into 
another draft. To avoid misunderstanding: I like the section but I think the place is 
wrong.   

section 6.5: Same comments as to 6.4

section 6.6: Again why is this in requirement section? I am not sure if it is a good
idea to have some complex capability negotiation as part of IPFIX. How does this
section relate to the IPFIX configuration? There seems to be some overlapp.

section 6.6.1:

It is possible that several protocols (e.g. LFAP, CRANE, Netflow, Diameter) meet the 
IPFIX requirements.  In this case, this capability is used to negotiate which protocol 
the end points will use. 

Does this sections tells me that there is no single IPFIX protocol but instead there
are a couple of protcols? So in the end we have a couple of protocols and each vendor
implements a different. ;-) I think there should be a standardized protocol.

section 6.6.2.6:

What is the exact definition of overlapping flows?

section 7:

This could be extended e.g. by adding about transport protocol in the scanrios.

-- Sebastian

--
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: <[email-masked]>
Date: Mon, 11 Feb 2002 08:14:53 -0500

>out of scope of the draft.

Architecture should address both architectural requirements and should be support 
a mechanism for identified applications.  

I also agree  some extent is may be out of scope  and should be in 
applicability document we do not have one separate deliverable for this and this is 
the reason we covered in the architecture.

>terminology drafts includes these

Agree.

>The exporter does measurement?

It is a logical functions it is upto the implementation where to place the functionality whether in exporter or collector or some other component.
 Logically the ideal place could be  on exporter, where it is close to the traffic. 

>information to flow record but the exporter certainly does not 

Agreed. 

>classification and statistics 

Yes.

>flow statistics? Can't the

May be for off-line analysis.

Regards
Ramg