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

[[e-mail]]

Kevin Zhang wrote:
> 
> 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.


	I agree 100%. And the opposite is also true,
	why would we ignore intra-net deployments and only consider
	Inter-net deployments? Especially when Intra-net is more
	prevalent (I didn't say exclusive, just more prevalent).

	BTW - I don't think WAN == Internet. 

> 
> >
> > >
> > > ++ 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/
> >
> >
> >

--
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/