Subject: [ipfix] draft-ietf-ipfix-architecture-01.txt

From: "K.C. Norseth" <[email-masked]>
Date: Mon, 15 Apr 2002 15:49:31 -0600

Hello folks,

While waiting for the draft to come out more officailly, here is version 1
of the architecture draft.

http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-01.txt

K.C.

--
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: "kevin.zhang" <[email-masked]>
Date: Mon, 29 Apr 2002 21:44:15 -0400

Hi All,

I have the following comments regarding section 5.1.2 and section 5.1.4 in draft-ietf-ipfix-architecture-01.txt.

I quote from our charter, the IPFIX system MUST - 
" Ensure that the flow export system is reliable in that it will
   minimize the likelihood of flow data being lost due to resource
   constraints in the exporter or receiver and to accurately report
   such loss if it occurs."

As minimizing the flow data loss is a primary goal, I believe the functionality specified at the export process and collector is not sufficient.  I thus propose the following modifications -

-------------------------
Original -
5.1.2. IPFIX Protocol on IPFIX Device (At Export Process)

     1. Ability to detect loss of connectivity with the collector and
        trigger the appropriate action (eg. a switch over to an
        alternate collector.)
     2. Optionally export flow records to multiple collectors.
     3. Monitor control information/flow record export, detect any
        overload in the process of exporting.
Modifications -
5.1.2.  IPFIX Device (at Export Process) Functionality

1.  Ability to detect loss of connectivity with the collector and trigger the appropriate actions (e.g. a switch over to an alternate collector)
2.  Optionally export flow records to multiple collectors.
3.  Optionally re-transmit flow records upon indications of flow record losses from the collector.
4.  Monitor control information from the collector and export process, detect any overload conditions in the export process and/or the collector.
------------------------------------

------------------------------------
Original - 
5.1.4. IPFIX Protocol on Collector

     1. Monitor the reception of export packets from IPFIX device.
     2. Optionally notify the status and overload conditions to the
        IPFIX device.

Modifications - 
5.1.4. Collector Functionality
1.  Receive and decode the flow records from the IPFIX devices.
2.  Ability to indicate flow record losses to the exporting IPFIX device and/or IPFIX users.
3.  Optionally notify the status and overload conditions to the IPFIX device.
-----------------------------------------

Thanks,

Kevin
ÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þwýÚ"·ü"±ÏÞvæ§vÆ²þéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ

---

From: Benoit Claise <[email-masked]>
Date: Tue, 30 Apr 2002 17:16:39 +0200

Hi Kevin,

> As minimizing the flow data loss is a primary goal, I believe the functionality specified at the export process and collector is not sufficient.  I thus propose the following modifications -

I don't like too much the term "re-transmit".
What if you don't have the flow records anymore?

> 4.  Monitor control information from the collector and export process, detect any overload conditions in the export process and/or the collector.

"Monitor control information from the collector and export process".
I think this is confusing. We really want to monitor 2 things:
- the control information
- the export process
And not the control information from the export process, as we could understand it from your sentence.

I disagree with "the overload conditions on the collector", we are concentrating on the exporter
From the requirements draft:
2.6. Collector

   The collector receives flow records from one or more export
   processes.  The collector might process or store received flow
   record, but these actions are out of the scope of this document.

Agreed.

Regards, Benoit

---

From: "kevin.zhang" <[email-masked]>
Date: Tue, 30 Apr 2002 14:00:34 -0400

Hi Benoit,

Please see my comments. 

> -----Original Message-----
> From: Benoit Claise [mailto:[email-masked]]
> Sent: Tuesday, April 30, 2002 11:17 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [ipfix] IPFIX-architecture Section 5
> 
> 
> Hi Kevin,
> 
> 
> > Hi All,
> >
> > I have the following comments regarding section 5.1.2 and 
> section 5.1.4 in draft-ietf-ipfix-architecture-01.txt.
> >
> > As minimizing the flow data loss is a primary goal, I believe 
> the functionality specified at the export process and collector 
> is not sufficient.  I thus propose the following modifications -
> >
> > 1.  Ability to detect loss of connectivity with the collector 
> and trigger the appropriate actions (e.g. a switch over to an 
> alternate collector)
The IPFIX protocol should support application level reliability as user desires.  This is why I added "re-transmission" as an optional exporter functionality.  My understanding of the IPFIX protocol is that we need to provide adequate mechansims that would allow different user requirements (e.g. reliability, redundancy, performance related considerations) being addressed. Whether these capabilities are invoked by the IPFIX users (applications using IPFIX protocol)would be implementation specific. 

> >
> > 4.  Monitor control information from the collector and export 
> process, detect any overload conditions in the export process 
> and/or the collector.
> 
I agree, this is acutally what I meant. How about changing it to "Monitor control information from the collector, monitor export process, detect ..."

> are concentrating on the exporter

IPFIX protocol is split between exporter and collectors.  If the collector can indicate the overload condition, the exporter should detect it and take actions just as overloading at the export process.  We are addressing an IPFIX system, and try to "Minimize" losses as charter outlined. Detection of collector overloading is one way of minimizing losses, as there's no point to sending to a overloaded collector, where data is dropped; instead, fail-over to a redundant collector would be a much better approach.

> > ÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ 
> yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þwýÚ"·ü"±ÏÞvæ§vÆ²þéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€
> Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+ÞÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þwýÚ"·ü"±ÏÞvæ§vÆ²þéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ