Subject: [ipfix] Questions regarding draft-gsadasiv-ipfix-proposal-00

From: Robert Lowe <[email-masked]>
Date: Tue, 12 Feb 2002 09:55:33 -0600

Hi!

Just a few simple questions from a lurker here, that perhaps Ganesh or Benoit 
can best answer.  Please excuse me, if I've overlooked something in my rather 
quick reading of this.

Section 4.1

If detection of a collector crash is impossible only because of the underlying
transport, e.g. UDP, why not add an _optional_ keepalive exchange between exporter
and collector?  This would still not introduce as much overhead as using a
reliable transport, or introduce multiple control information connections
when using redundant collectors, as you outline in section 4.2.

Section 5.4

You mention that templates should be periodically sent from exporter to 
collector.  If the collector were to acknowledge receipt of these, could
this not act as a simple keepalive as well?  Granted, this is not something
one would want to have happen frequently.  Am I to assume that the collector
can initiate these as well?  I'm not advocating this as a form of capability
negotiation (see below).

---------

A few more comments regarding templates, although ones which probably fall
within the realm of operational vs. protocol issues...

Early on there was some discussion regarding the impact of IPFIX on the
network itself, and if/how the exporter or collector should react to
overload conditions.  As I recall, Peter Phaal indicated that from an
analysis point of view, it would not be good to change the sample rate.
However, when faced with an overload condition:

1) On the exporter, should it:
	a. continue as is, and drop packets when it has to, or
        b. fall-back to a user pre-defined sampling rate, compromising
           IPFIX data to avoid dropping packets ??

2) On the collector, should it:
        a. continue, and lose flow data because it cannot process it all, or
        b. signal a fall-back to a different sampling rate via a new template?

If the solution uses the verb "buy", don't mention it!  ;-)  I can accept a
good argument that these are operational issues.

Also, this could be related to how an exporter deals with DoS attacks, which
I haven't heard anything about recently.  Perhaps all of you gentle folk
talk about this stuff at IETF meetings, which I don't get to attend.

-Robert

--
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: Tue, 12 Feb 2002 08:51:48 -0800

> when using redundant collectors, as you outline in section 4.2.

This could be done.

> can initiate these as well?  I'm not advocating this as a form of capability

One can mix data & control stream into one. ACKing becomes an overhead
in such a case.

>            IPFIX data to avoid dropping packets ??

a. would be the default but keep a count of what gets dropped.
. b. is optional since not all devices may be able to support this.

>         b. signal a fall-back to a different sampling rate via a new template?

a. would be the default.
b. is in the lines of inband config. I would say raise an alarm to the management
station which decides the appropriate action to be taken.

Thanks
Ganesh