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

["Kevin Zhang" <[e-mail]>]

Hi Paul,

I have to disagree with you, please see my comments.

Thanks,

Kevin

> -----Original Message-----
> From: majordomo listserver [mailto:[e-mail]]On Behalf
> Of [e-mail]
> Sent: Monday, March 11, 2002 12:12 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [ipfix] Mailing list digest, Friday 8 March
> 
> 
> [e-mail] wrote:
> > 
> > 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?
> >    - 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.
> 
> 
> 	I believe there are a large number of real world deployment 
> 	cases where IPFIX is not going over the Internet. In fact,
> 	it is likely to be the majority of deployment cases. Is there
> 	disagreement on this point?
> 
> 	If not, we ought to decide the best way to solve the problem
> 	first, then decide what that means for us as an IETF group;
> 	not the other way around.
> 
> 
I believe CRANE protocol (http://search.ietf.org/internet-drafts/draft-kzhang-crane-protocol-02.txt) is considered as a candidate for IPFIX.  We have several deployments with tier one carriers, which the exporter and collectors communicate through WAN. Furthermore, potential IPFIX exporting devices may be routers, probes, and mid-boxes as outlined in our charter; I do not agree that the need of high-speed router (may have limited on-device flow processing capability) should over-ride all the other needs.  

> 
> > 
> > ++ 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.
> > 
> > -------------------------------------------------------------
> > 
> > ++ 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?
> > 
> > ++ 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
> > 
> > ++ Applicability document
> >    ** Material currently in Arch draft.  Discuss at Minneapolis meeting.
> >       Charter mentions it to support Architecture draft, so its
> >       OK to start work on this, but don't let it distract from other
> >       WG drafts!  Use ipfix-app list alias for discussion.
> >    - Carter, 20 Feb: OK, but don't go too far off topic
> >    - KC, 20 Feb: Renaldo, Kevin & Tanja contributed most of 
> this material
> >      in Arch, they'd be good editors
> >    - Tanja, Feb 19: 'Applicability' contents proposal
> >    - Proposed by KC, support from Benoit
> > 
> > ++ Middleboxes document
> >    *** Not in scope, material currently in Arch draft.
> >        Do we need a separate document?  Or put it in 
> Applicability draft?
> > 
> > ++ Selecting a Flow Info Export protocol
> >    ** Our charter says we'll select a protocol, however we'll probably
> >       need to look (small) improvements to an existing protocol
> >    - 19 Feb: KC had intended to list 'overview' descriptions of existing
> >      protocols in Arch draft.  Paul thinks this is premature, 
> we should list
> >      'selection criteria' there instead.  KC agrees, meantime (so as not
> >      to loose the contributed text from B/G and Kevin) we'll 
> shift it into
> >      appendices.
> >    - Randy, 18 Feb: realistically, i think you will have to 
> modify any of
> >      the existing protocols to meet robust needs.  and yes, i think
> >      security should be a consideration.  [ note that snmpv3 control and
> >      tcp export over ipsec may meet some of the more difficult 
> issues you
> >      raise ]
> >    - David, 18 Feb: Selection criteria are needed for this!
> > 
> > ++ Defining a flow
> >    - Paul, 19 Feb: Selection process chooses packets to consider,
> >      flow definition rules determine which unique flows to export,
> >      i.e. flow definition rules may define sub-flows.  Collector may
> >      wish to know the selection cfriteria.
> >    - Reinaldo, 19 Feb: Is a subset of a flow (i.e. one formed by adding
> >      another filter function) not 'just another' flow?
> > 
> > ++ Overload conditions
> >    - KC/Robert, 13 Feb: Should exporter or collector be allowed to hanle
> >      overload by changing sampling rate?  Or is it better to loose
> >      packets instead?
> > 
> > ++ Security Considerations
> >    - Cliff, 12 Feb: text for Arch draft
> > 
> > B/G = Benoit & Ganesh
> > 
> > Benoit Calise, Cisco
> > Carter Bullard, QOSient
> > Christian Gilby, Nortel
> > Cliff Wang, SmartPipes
> > David Harrington, Enterasys
> > Fred True, AT&T Research
> > Ganesh Sadavisan, Cisco
> > Jean-christophe Martin, Sun
> > Juergen Quittek, NEC
> > KC Norseth, Enterasys
> > Kevin Zhang, Xacct
> > Man M Li, Nokia
> > Mark Fullmer, OARnet
> > Paul Calato, Riverstone
> > Peter Ludemann, Xacct
> > Ram Gopal, Nokia
> > Randy Bush (AD), AT&T
> > Reinaldo Penno, Nortel
> > Sebastian Zander, Fraunhofer Institute FOKUS
> > Simon Leinen, Switch
> > Tanja Zseby, Fraunhofer Institute FOKUS
> > Venkatraman G, Infosys Technologies
> > Will Eatherton, Cisco
> > 
> > ++Other comments
> > 
> > Robert Lowe <[e-mail]>, 15 Feb:
> >   The lurker opinion poll (no vote)... ;-)
> >     In-band configuration -- not now.
> >     Negotiation -- limited (but that discussion is promised to follow).
> >   Benoit, I think this was a very perceptive comment.  It seems we are
> >   at times confusing the two.
> > 
> > Peter Phaal <[e-mail]>, 13 Feb:
> >   The IPFIX charter doesn't address the algorithms used by the flow
> >   collector, but there are system-wide issues that should be explored.
> >   Design choices made in the IPFIX protocol specification can have a
> >   fundamental effect on the capabilities of traffic management systems
> >   collecting IPFIX data (scalability, latency, accuracy, multi-point
> >   correlation, etc.)
> > 
> > -----------------------------------------------------------------------
> >    Nevil Brownlee                   Director, Technology Development
> >    Phone: [phone] x8941      ITSS, The University of Auckland
> >    FAX: [phone]      Private Bag 92019, Auckland, New Zealand
> > 
> > --
> > Help        mailto:[e-mail] and say "help" 
> in message body
> > Unsubscribe mailto:[e-mail] and say
> > "unsubscribe ipfix" in message body
> > Archive     http://ipfix.doit.wisc.edu/archive/
> 
> --
> Help        mailto:[e-mail] and say "help" in 
> message body
> Unsubscribe mailto:[e-mail] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 
> 
> ÿñޖ™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&ޙ¨¥¶æj:+v‰¨þw­ýÚ"·ü"±ÏÞvæ§vƲþéì¹»®&ފ—âÇø§™ë,j›¡Ü€­Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ