Subject: RE: [ipfix-req] IPFIX Requirement draft status - section 5.8

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 1 Oct 2002 20:42:18 -0700

Hello Paul,

I think that the ipfix *Architecture* needs to cover more than the protocol.
But the protocol should cover only..the protocol. Maybe the right word is
"solution"...

I mean, the solution/architecture ( IPfix internal device implementation +
IPfix protocol) must meet certain requirements (metering, observations
domains, scalability, etc, etc)...

But the evaluation of the protocol part IMO shouldn't take into
consideration metering requirements such as the one I posted. Let's see if
there are other opinions on this besides Peter's. 

regards,

Reinaldo

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 01, 2002 9:49 AM
> To: Peter Ludemann
> Cc: Penno, Reinaldo [BL60:0430:EXCH]; req;
> [email-masked]
> Subject: Re: [ipfix-req] IPFIX Requirement draft status - section 5.8
> 
> 
> 
> I think maybe you are using to narrow a definition of the
> term "protocol". The IPFIX protocol specification needs to 
> cover more than the message format and message exchange. 
> 
> Paul
>

---

From: Jeff Meyer <[email-masked]>
Date: Tue, 01 Oct 2002 23:00:49 -0700

Reinaldo,

   I completely agree that there are requirement aspects
that have nothing to do with the export protocol.  Given
the focus on protocols, changing non-protocol requirements
now only confuses things.

Regards,

   Jeff Meyer

Reinaldo Penno wrote:

> Hello Paul,
> 
> I think that the ipfix *Architecture* needs to cover more than the 
> protocol. But the protocol should cover only..the protocol. Maybe the 
> right word is "solution"...
> 
> I mean, the solution/architecture ( IPfix internal device implementation 
> + IPfix protocol) must meet certain requirements (metering, observations 
> consideration metering requirements such as the one I posted. Let's see 
> if there are other opinions on this besides Peter's.
> 
> regards,
> 
> Reinaldo
> 

--
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: "Peter Ludemann" <[email-masked]>
Date: Tue, 1 Oct 2002 23:38:12 -0700

RE: [ipfix-req] IPFIX Requirement draft status - section 5.8I would like to
make a stronger statement than has been attributed to me:
  a.. The protocol should cover only the issues of delivering data from the
exporter to the collector. It must be expressive enough to contain all the
data defined in the data model.
  b.. The data model should cover the identification of the metrics and
attributes, their meanings, and how they are grouped together.
  c.. The architecture should cover issues such as where data are observed,
what data are required and what are optional, when reliability is needed,
how the data can be manipulated (e.g., calculating bandwidth), etc., etc.
This is classic computer science "divide and conquer".

Each layer from protocol, to data model, to architecture, is more complex
and more likely to cause argument. So, I have confined my comments to the
protocol, even though we also have a "probe" and would like to see
standardization of its metrics and attributes.

In the end, even the most formal models end up with words describing bits.
(And, yes, I would include denotational semantics and related esoterica in
this sweeping statement.) So, there must be precise agreement on the
definitions of the data types and the standard names used. As a simple
example, from our PacketSight probe, does "response time" for HTTP flows
mean:
  a.. TCP-level response (time between seeing the SYN and ACKs)
  b.. TCP/application-level response (time between sending the SYN and
sending the first GET)
  c.. application-level response (time between the first or last packet of
an HTTP GET and the first or last packet of the response or of the first or
last packet of the payload) [6 possibilities]
  d.. how should application-level response be interpreted for status
responses such as 3xx (redirection), 404 (file not found), or 5xx (server
error)?
  e.. does the definition take into account out-of-order or duplicate
packets?
  f.. what is the application-level definition with persistent connections?
  g.. etc., etc.
(which is why I've been leaving myself out of the discussions -- I just
don't have time to discuss these interesting issues.)

We anticipate standard names for some measurements being defined in the
future; but we also wish a protocol that is completely open, so that people
can define whatever they want. In a sense, it is like a high performance
ODBC, which only requires that both client and server agree on the meanings
of the record fields.

By the way, we intend to use CRANE for more than just IP flow export ...
other candidate uses include collecting telephony CDRs, QoS metrics
(formerly done with SNMP), web server logs, etc.

- peter
  -----Original Message-----
  From: Reinaldo Penno [mailto:[email-masked]]
  Sent: Tuesday, October 01, 2002 8:42 PM
  To: [email-masked]; Peter Ludemann
  Cc: req; [email-masked]
  Subject: RE: [ipfix-req] IPFIX Requirement draft status - section 5.8

  Hello Paul,

  I think that the ipfix *Architecture* needs to cover more than the
protocol. But the protocol should cover only..the protocol. Maybe the right
word is "solution"...

  regards,

  Reinaldo

---

From: Sebastian Zander <[email-masked]>
Date: Wed, 02 Oct 2002 10:21:13 +0200

Hi Reinaldo,

the requirements draft lists requirments for IP flow export. It is not
limited to protocol requirements. I completly agree to you that some
of the requirments are not applicable for the protocol but I assume that
the eval team will not consider those.

Cheers,

Sebastian

-- 
Sebastian Zander                         E-mail: [email-masked]
FhI FOKUS / Global Networking (GloNe)    Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany                  www.fokus.fhg.de/usr/sebastian.zander

---

From: [email-masked]
Date: Wed, 02 Oct 2002 08:26:13 -0400

> I mean, the solution/architecture ( IPfix internal device
> implementation + IPfix protocol) must meet certain requirements
> (metering, observations domains, scalability, etc, etc)...
> 
> consideration metering requirements such as the one I posted. Let's
> see if there are other opinions on this besides Peter's.

	Agreed. Your choice of terms works for me as well.
	Basically "messages & message formats" == "protocol"
	and "protocol + processing/semantics" == "architecture".

	Paul