Subject: [ipfix-eval] IPDR response to evaluation drafts

From: Jeff Meyer <[email-masked]>
Date: Thu, 24 Oct 2002 13:15:47 -0700

Hi,

   I wanted to respond, from an IPDR perspective, to the two
evaluation drafts submitted.

   http://ipfix.doit.wisc.edu/archive/1266.html (Simon)
 
http://ipfix.doit.wisc.edu/archive/att-1277/01-draft-gopal-ipfix-eval-00.txt 
(Ram)

   At a high level, I found that Simon's draft provided a
pretty balanced view of the various candidates and their
capabilities.  In particular IPDR was accurately portrayed.

   Ram's draft seems to reflect some misconceptions about
IPDR (often misspelled as IDRP).  It is probably a combination
of the newness of IPDR in this community and the lack
of my writing ability to more clearly explain how
IPDR is used to address IPFIX.  I think Simon's
summary in section 2.5 does a good job of characterizing
IPDR.

   Specific comments on Ram's submission relative to
streaming IPDR.

2.3  "IPDR... does not explicitly describe the IPFIX
architectural requirements".

   IPDR does address the requirements for an IPFIX
exporter process, hence the advocacy draft.  Streaming
IPDR defines a lightweight accounting protocol, which
is primarily unidirectional.

   IPDR only addresses the "Exporting Process" part of
the IPFIX model and its interaction with one or more
"Collecting Processes".  CRANE, Diameter and IPDR are all
examples of protocols whose focus is solely on the
exporting process, putting no restrictions on the
behavior of the "Metering Process".  I would contend
that a clean separation of the exporting process
from the control of the meter (for instance via
a Meter-MIB) is desireable.  NetflowV9 also appears
to address only the exporting activity and not
the meter control.

3.1.x Grades and Comments

   Given the separation of most candidate protocols from
the Metering Process itself.  I am unclear how some
of these results were arrived at.

   For example in section 3.1.2 Sampling (5.2) the
discussion says that IDPR (sic) is an "F" and that
Diameter is an "E".

   As stated in the IPDR advocacy draft:

    Please note that the requirements specified in sections 4, 5 and 7.1
    of IPFIX Requirements [1] do not directly concern the IPFIX protocol,
    but the semantics of the data transferred.  They can be met easily by
    extensible protocols that do not restrict sematics of transferred
    data.  This includes the Streaming IPDR format, as the data model
    allows for arbitrary extension, following a well established
    standard, XML Schema [4].

  In Diameter, there is an explicit statement for
this requirement:

    This requirement is a metering process requirement. However the
    IPFIX protocol must support to export some information about
    sampling configuration.  New (grouped) AVPs can be defined for
    carrying the sampling configuration.

  I believe these two statements are equivalent in their approach.

  In 3.1.3 Overflow.  IPDR got an "E" and Diameter gets an "F",
where in both cases, the same logic applies as for sampling.

  Similar issues are in 3.1.5, 3.1.6, 3.1.7, and 3.1.8.

  Basically if the protocol is extensible (through standard
descriptions or templates or AVPs) then the additional
information which a Metering Process needs to provide
can be equally addressed by all candidates.  One may
argue that LFAP has explicit protocol operations to
address some meter behavior.

  In section 3.1.11, data model.  Describes the use of
XML, but does not indicate that XDR is the wire format
for the information.

  In section 3.1.15, security.  Raises the question of
whether XML security would be used.  The protocol
communication does NOT use XML, so this would not
be appropriate.  Think of SNMP.  I don't need a MIB
compiler to send an SNMP request.  Likewise with
IPDR, you don't need an XML processor to use
StreamingIPDR.

Regards,

   Jeff Meyer

--
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: Fri, 25 Oct 2002 01:56:24 -0400

Hello Jeff,

Comments are inline.

> summary in section 2.5 does a good job of characterizing

Sorry for using wrong abbreviation.
 
> is primarily unidirectional.
If you read the draft for the first time after going through the IPFIX 
requirements and architecture, the draft simply explains the interactions
between two TCP endpoints and XML message schema. There is a little amount 
of discussion about the capabilities of the endpoints.  It would recommend 
by explaining few sentences in relation to IPFIX architecture.

>     standard, XML Schema [4].

Metering process is the capability of the endpoint and it has little thing
to do with the XML scheme. 

>     carrying the sampling configuration.

Sampling is an operation ( or procesing ) capability of metering endpoint.
 
> where in both cases, the same logic applies as for sampling.

Can you revisit, If you feel that there is an explicit requirement of metering
in your protocol endpoint please document so.  It's good that you opened the discussion,
if you have any other hidden functions or features, please send an email  this will 
speed up the evaluation process.

> IPDR, you don't need an XML processor to use

Good explanation, It was more of a clarification. I have not commented anything 
against your the proposal.
As the document was silent in describing security, I gave my view on that.
 
Document initially mentioned XML and XDR. It was my impression that my TLS or IPsec can
be an ideal candidate, since XML is being used between two endpoints XML security also be 
considered.

What you represent as a flow using XML can be conveyed in wire in may different format and this 
is the basic confusion.

Regards
Ramg