Subject: RE: [ipfix] Mailing list digest, Friday 8 March

From: "Reinaldo Penno"<[email-masked]>
Date: Sat, 9 Mar 2002 16:34:04 -0800

Hello Nevil/KC/All,

Some comments on this digest...

First of all I suggest we put together a small team of volunteers to come up
with a presentation (doesn't even need to be a document) explaning what is
in-band configuration, capabilities negotiation, content negotiation and
other so we can start discussing based on a well understood terminology set.

Even with the middlebox material out of the arch draft (today is in the
applicability doc) we need to put something there to suggest how to behave
in face of these services. I suggest something like:

"An exporter may be involved in providing services that require 
application level intelligence and/or transform or filter content such 
as middlebox and OPES respectively. 

When involved in services that transform or filter content such as (but not
limited to) 
NAT, Request Routing and Policing the exporter MUST be able to indicate on
the flow 
record what changes were made to the packet."

other comments inline...

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Friday, March 08, 2002 7:56 PM
>To: [email-masked]
>Subject: [ipfix] Mailing list digest, Friday 8 March
>
>
>IPFIX Co-chairs list of IPFIX issues
>
>Nevil Brownlee & Dave Plonka, Fri 8 Mar 02
>
>++ marks each issue
>** WG co-chairs comment
> - Mailing list discussion items
>
>   Contributors names are listed in full following the list of issues
>
>++ Congestion-aware protocols
>   ** Need to reach consensus on two major points:
>       a. We know we need reliable transport.  Do we
>          also need unreliable?
>       b. Given consesnus on (a), how do we provide
>          congestion awareness?

My vote is for a reliable protocol. Congestion awareness is already built-in
on TCP ands SCTP.

>   - Nevil, 4 Mar: Note setting out IESG / WH chair position on
>     this issue.  In brief, if IPFIX doesn't mandate congestion-
>     aware transport, the WG RFCs won't get approved.
>
>++ Collector Failover
>   ** We need a control session handling keepalives.
>      Much of this discussion hinges on the TCP vs UDP debate!
>   - Paul, 27 Feb: Need to handle 'lost data' no matter what!
>   - Mark, 25 Feb: UDP with retransmits as an alternative to TCP
>     or SCTP.  A TCP for keepalives could be enough?
>   - Paul/Ganesh, 25 Feb: Not convinced that UDP can be ruled out;
>     TCP on its own doesn't provide 'application level reliability.'
>   - Peter, 25 Feb: 'Reliable' transport is better and simpler. "Any 
>     data delivery method that avoids reliability simply 
>pushes things on
>     to another part of the system."  Use SCTP or TCP; data ACKs
>     are enough, don;t need keepalives as well.
>   - Mark, 23 Feb: Suggestions: use mandatory TCP control connection,
>     require collector to send periodic ACKS to exporter.
>   - Peter, 23 Feb: TCP keepalive not enough for exporter to detect
>     crash of collector.  Need to either use SCTP or have a failure
>     detection mechanism.

I'm not sure what is my position in the collector failover debate. I would
tend to vote in favor of SCTP instead of assuming certain things that TCP
does not provide, such as keepalives, periodic acks, etc.

Otherwise it would be better to put it on the application layer and have a
special health check mechanism that does not only check if Layers 1-4 are
working but also the application itself, just like L7 switches today.

>
>
>-------------------------------------------------------------
>

I tought we reached a consensus on this. It was to support absolute counts
(counters) and deltas. 

>++ Counter wrapping, long-running flows
>   ** Support for both absolute counts (counters) and deltas, no clear
>      consensus.
>   - Benoit, 22 Feb: Close flow and export it when it nears 
>counter wrap,
>     restart as a new flow.
>   - Ganesh, 21 Feb: Export flow records when counters go past 
>a threshold,
>     Keep IEs for absolute counts or delta counts, whichever is needed.
>   - Peter, 21 Feb: In our experience, it's better to output 
>deltas. Absolute 
>     values are needed only if you have an unreliable data exporter.
>   - KC, 21 Feb: Ability to send a flow record at any interval 
>due to a 
>     counter rollover needs to be a selection criteria.
>   - Reinaldo, 19 Feb: Could someone elaborate on this?
>
>

This configuration/negotiation part goes back to my original suggestion.

>++ Configuration: protocol
>   ** Out of scope, i.e. WG should not consider this until we have
>      the Arch and Data drafts well under way.
>   - KC, 20 Feb: not doing that, trying to select best of 
>existing protocols
>   - Randy, 20 Feb: reminder, out of scope 
>   - Reinaldo, 20 Feb, IPFIX config protocol needed, MIB OK as well
>   - Fred, 20 Feb: NetFlow v9: good summary posting 
>       'bi-directional config' = collector can ask exporter 
>for reqd flows
>       Fred doesn't think it would be useful, lots of IOS development,
>       implications for reliability, security, etc.
>       Config via an 'IPFIX Configuration MIB' would be better.
>   - Juergen/Reinaldo/Paul/Benoit/Ram, 14 Feb: 'Not trying to 
>standardise
>     meter, therefore don't specify how to configure one.'
>   - Mike, 13 Feb: Configuration and MIBs: "A MIB module is a 
>concise guide
>     to implementors in their design of a configuration 
>interface (CLI, XML,
>     XYZ, whatever) to manage a given techology"
>   - Mark, 12 Feb: Comments on exporter-collector session management,
>     session IDs.
>   - Will, 11 Feb: Doesn't want 'SHOULD support in-band configuration.'
>
>++ Configuration: Content Negotiation
>   - Christian/Peter/Juergen, ~19 Feb: Collector should be 
>able to request
>     a subset of all available flow attributes, exporter 
>should indicate
>     which  attributes it can send.
>   - Benoit, 19 Feb: This is pure configuration.  You tell the exporter
>     which fields to export by defining a template.
>
>++ Configuration: In-band Configuration
>   - Christian/Peter/Juergen: This is the ability for a collector to
>     ask an exporter for a particular set of flows
>
>

---

From: "Norseth, KC" <[email-masked]>
Date: Mon, 11 Mar 2002 14:21:46 -0500

Hi Reinaldo,
 
I was mostly unavailable for the last week, and am now starting to read the
mail.  
 
For issues we want to discuss as part of the archecture, lets put them in.
That is being worked on now.  Ganesh and I will be putting together the arch
presentation this week, but for issues that are not yet fully defined, we
have a place to put them.  There are several issues we need to clarify and
they need to be done this meeting.
 
 -----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Saturday, March 09, 2002 5:34 PM
To: [email-masked]; [email-masked]
Subject: RE: [ipfix] Mailing list digest, Friday 8 March

Hello Nevil/KC/All, 

Even if we don't have a "team" to do this, if we can come up with a couple
of slides on these items for discussion, we can put it in the arch
presentation.  I want to see closure at this conference.

Agreed. 

other comments inline... 

>From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] 

A Completly unreliable protocol is dangerous. I don't want to explain to my
customers that they cannot rely on getting all their flow information from
the router,  UDP can also be made more reliable with some handshaking.