Subject: Re: [ipfix-arch] Re: IPFIX Architecture

From: Benoit Claise <[email-masked]>
Date: Wed, 06 Feb 2002 23:42:31 +0100

Hi Kevin,

A couple of important points I would like to discuss amongst the group [I haven't copied the entire document]
G: stands for Ganesh
Kz: Kevin Zhang
Ben: Benoit

G:
The underlying transport or other protocol is something which can be
configured by the sys. admin., whatever the way he wants:
CLI, SNMP, telnet, ...
G:
[kz3] What you are saying is correct.  It depends on whether you want to do it in-band within the export protocol or
out-band.  However, do it within the protocol improves interoperability significantly which is exactly this WG is
trying to achieve.
[kz]

[Ben] I don't know how it improves the interoperability to do the configuration inband.
IPFIX stands for Flow Information eXport. So we have to standardize the export, not the configuration. So the
direction:exporter -> collector and not the direction collector -> exporter. At least not for the configuration.
Standardizing the configuration is a huge job. Do you think that vendors will spend time and money to developp again
another configuration interface, next to CLI, SNMP, XML, etc...? And this just for an IPFIX protocol!
What I'm thinking is that the configuration of the probe or the router is out of the scope of this document and is
based on proprietary solutions. Proprietary solutions that you will very hardly standardize, because they all
contains different proprietary features.
[Ben]

[kz2] "capability negotiation" is a MUST, this is key for the IPFIX system to be flexible enough to deal with various
exporting devices (besides core routers).  Your view is router-centric, at least in a probes case, what to collect,
how to collect, and when to export are typically configurable by the applications through the collector.
Furthermore, exactly due to the existing infrastructure, "capability negotiation" would be key for the exporter and
collector to understand what are the lower layer support (e.g. security, transport protocol, etc.) for the interace.
[kz]

[Ben] Well, I guess that I have a "router-centric" view as you call it ;)
As I expressed before, my view is that, because the exporter configuration must happen out-of-band, capabilities
negotiation should not happen.

1. Neither capabilities negotiation for the exported fields in a template:
because the template is based on what the exporter can do, not on what a collector thinks an exporter can do.
In other words, you configure the exporter template (by whatever means), the transport protocol and where to export.
Then the collector must be able to parse all the fields of the template.
I refer you to section 8 of http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt for more details
of what I'm thinking.

2. Neither transport protocol negotiation.
The transport protocol is the first thing you will decide on in an accounting network design (accouting being just a
generic term).
I mean, depending if you want to be billing or traffic monitoring, you may use a connection-oriented transport
compared to UDP, with or without IPSEC.
Basically, you won't change very often your transport protocol.
So why would like to invest time in a transport protocol negotiation?
I would say that this would be configured once for all before you even start exporting the first flow record.
[Ben]

G:
Fail-back is not possible on a router -> too much memory needed.
The best we can do is fail-over.
G:

[kz6] I don't see big difference for memory requirement between fail-over and fail-back, would you please providing
more details?
[kz]

[Ben]
Fail-over means that as soon as you detect that the connection (only in case of a reliable transport protocol, not
UDP) to the collector is lost, you can start sending to another collector. You may loose a few flow records depending
on your transport protocol keepalive.
Fail-back means that if we switch to another collection, we can' t loose any data.
Again maybe a router-centric view ;), but Ganesh showed at the last IETF how much data we can produce per second when
exporting from a router.

I refer you to section 4.1.3 and 4.2.3 of http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt
for more details of what I'm thinking.
    4      Flow Export Protocol  ...................................   9
    4.1    Simple Export Model  ....................................  10
    4.1.1  Collector Crash  ........................................  10
    4.1.2  Collector Redundancy  ...................................  10
    4.1.3  Collector Failover  .....................................  10
    4.2    Export Model with Reliable Control Connection  ..........  10
    4.2.1  Collector Crash  ........................................  11
    4.2.2  Collector Redundancy  ...................................  11
    4.2.3  Collector Failover  .....................................  12
[Ben]

  -  Re-sequencing the received IP flow information if required. In
  case a reliable, in-sequence delivery service is provided by lower
  layer protocol, this function can be omitted.
G:
If we have the timestamp per flow why is resequencing required
G:
[kz7] Timestamp is not sufficient to detect message losses, particularly when unreliable transport protocol is used.
[kz]

[Ben]
Right, but you can still have a sequence ID in the packet which will tell you if you are loosing some packets.
Is this what you have in mind when talking about re-sequencing?

Regards, Benoit
[Ben]

--
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, 08 Feb 2002 11:38:57 -0500

My comments inline.

> contains different proprietary features.

	I agree we don't want to try and solve the entire
	config issue in band. But that should not rule out
	some simple negotiation. For example, it seems appropriate 
	for the Collector to indicate what fields it is interested in. 

> I refer you to section 8 of http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt for more details

	Just because the exporter CAN send the data doesn't
	mean it should. It seems better to me to have some
	basic level of capability in all my exporters and
	then configure my collectors with the data of
	interest for my reports. 

> I would say that this would be configured once for all before you even start exporting the first flow record.

	I agree on this one.

> Fail-back means that if we switch to another collection, we can' t loose any data.

	fail-back might just be stop talking to the backup and
	go back to the primary.

> Again maybe a router-centric view ;), but Ganesh showed at the last IETF how much data we can produce per second when

	I don't think anyone at the meeting bought into those
	numbers. So this is not a good argument from my
	perspective.