ipfix@conference.ietf.jabber.com - 2003/03/20


[08:45] %% logger has arrived.
[11:43] %% sleinen has arrived.
[12:16] %% sleinen has left.
[16:50] %% sleinen has arrived.
[16:50] %% ggm has arrived.
[16:50] %% kurtis has arrived.
[16:50] <ggm> I'll be scribe. sack me at will.
[16:51] <ggm>
IP FLow Information eXport (IPFIX)

started at 3:30

Neville Brownlee, Dave Plonka are the chairs

http://ipfix.doit.wisc.edu/IETF56/ for slides

[16:52] <ggm> Juergen Quittek, IPFIX requirements doc changes v7 to v8
[16:53] <ggm> summary of whats changed
[16:53] <ggm> sec 2.1 ip traffic flow item 1 line 3
[16:53] <ggm> added ref to RTP spec
[16:53] <ggm> appended clarification
[16:53] <ggm> packet properties may depend on app headers. no requirement defined in this doc related to appl.headers
[16:54] <ggm> sec 4 distinguishing flows para 4 now para 3
[16:54] <ggm> appended
[16:54] <ggm> (sorry, missed it)
[16:54] <ggm> 5.2 minor change to sampling
[16:54] <ggm> 6.1 information model. more significant change
[16:54] %% mrose has arrived.
[16:54] <ggm> ICMP type and code moved from MUST to SHOULD report
[16:55] <ggm> 6.7 Anonymiser
[16:55] <ggm> MUST be clear to collecter is anonymized. otherwise may not realize its not real
[16:55] <ggm> 6.3.2 long long long text on reliability. go read the slides
[16:55] <ggm> not everyone happy but good compromise
[16:56] <ggm> any changes/questions? otherwise happy to close here
[16:56] <ggm> closed.
[16:56] <ggm> Benoit Claise. Netflow V9 eval against IPFIX reqts v 4.
[16:56] <ggm> only speak to changes since 3
[16:56] <ggm> is it implemented
[16:57] <ggm> is it in commercial use?
[16:57] <ggm> ICMP etc ...
[16:57] <ggm> sampling
[16:57] <ggm> at last meeting eval time commented on sampling part. extension needed
[16:57] <ggm> now total compliance for all of
[16:57] <ggm> adding samp func, removing change method, param
[16:58] <ggm> time sync was only partially compliant
[16:58] <ggm> total compliance with proposed solution.
[16:58] <ggm> add flow start/end times
[16:58] <ggm> exporter can periodicallty send an option templ with timesync
[16:58] <ggm> congestion awareness
[16:59] <ggm> adv. must elaborate
[16:59] <ggm> SCTP-PR for compliance
[16:59] <ggm> for more details. refer to draft
[16:59] <ggm> draft-djernaes-netflow-9-transport-00
[16:59] <ggm> two streams. one reliable (with templates)
[16:59] <ggm> still export flow records on partially reliable stream from router
[17:00] <ggm> doesn't prevent SCTP export of flows on reliable stream eg for billing
[17:00] <ggm> but there are conditions
[17:00] <ggm> don't want to export 20 flows maybe high aggregation in data. and memory (!)
[17:01] <ggm> Q from alex. connection awareness.
[17:01] <ggm> consensus was not good solution. CHair?
[17:01] <ggm> will be in next section of discussion. has to be considered, we're at 'where is the IETF giving us a connection standard'
[17:02] <ggm> draft says run on congestion aware proto, tcp or SCTP like
[17:02] <ggm> Reliability extensions
[17:02] <ggm> MUST be open to.
[17:02] <ggm> will get that with SCTP-PR. will be compliant
[17:02] <ggm> refer to draft.
[17:02] <ggm> [ is this ok? -ggm]
[17:02] <ggm> set of properties for distinguishing flows
[17:03] <ggm> totally compliant. the template ID, Observation domain, can find back the set of props for the flows
[17:03] <ggm> [summary: table from eval report. best look in the slides -ggm]
[17:03] <ggm> Q or Feedback...
[17:04] <ggm> Comment from floor. netflow v9. able to manage IPv6
[17:04] <ggm> A: in EFT right now. can put you in contact to discuss
[17:04] <ggm> ALEX rephrase Q again. I was ahead. relates to reliability extension. if you don't have SCTP, you aren't in compliance
[17:05] <ggm> A thats why we said its upcoming.
[17:05] <ggm> CHAIR
[17:05] <ggm> only one to update advocacy draft. not a lot of choices here.
[17:05] <ggm> EVAL RESULTS.
[17:05] <ggm> 3 members of team here. one communicating by email, one unreachable.
[17:06] <ggm> rough consensus from team is to use NetFLOW v9 as basis for IPFIX protocol
[17:06] <ggm> Attempt to quantify eval. in matrix. was dead end. no sifnificant new info appeared since last meeting
[17:07] <ggm> charter requests IPFIX protoco ameanable to router and instr. impl and to deployment
[17:07] <ggm> team beleives IPFIX proto based on NetFLOW v9 can be implemented in most network elements because it makes the least demands of the exporter
[17:07] <ggm> low overhead in linecard.
[17:07] <ggm> issues
[17:08] <ggm> once we have NF v9 as base, get consensus on list follow up by follows
[17:08] <ggm> subsecond timestamps to be dealt with
[17:08] <ggm> flow loss stats. make sure we detect individual flows be addressed
[17:08] <ggm> clarify exporter id isn;'t neccesarily the trans source address
[17:08] <ggm> opennes to reliability extns per requiremenets
[17:08] <ggm> failover at least reconsidered
[17:09] <ggm> draft-coene-rserpool applic-ipfix
[17:09] <ggm> referring to this activity
[17:09] <ggm> 3 members of eval team here
[17:09] <ggm> IMPL PROPOSAL
[17:09] <ggm> if reach consensus
[17:09] <ggm> specific initial transport is TCP
[17:09] <ggm> transition mech to enable rapid devel & deployment.
[17:09] <ggm> why?
[17:10] <ggm> ubiquitous. congestion controlled
[17:10] <ggm> IPFIX PROTO MUST NOT rely on TCPreliable delivery
[17:10] <ggm> MUST remain compatible with unrelaiable datagram delivery so it can be
[17:10] <ggm> ported to upcoming transports such as DCCP or PR-SCTP
[17:11] <ggm> [yo! is the notes ok? anybody care? -ggm]
[17:11] <ggm> next steps
[17:12] <ggm> floor. should be discussed on ML if eval process has changed.
[17:12] <ggm> how is eval to proceed. procedural issue
[17:12] <ggm> chair. same process. nothing has changed. we've matured. silence from ML for 3-4 months
[17:12] <ggm> thats the framework we're seeing this happen
[17:12] <ggm> one doc reached dead end.
[17:12] <ggm> other eval team drafts came to this decision
[17:13] <ggm> floor
[17:13] <ggm> right, some arrived at the conclusion in individual evals. but the last report suggested LFAP lead.
[17:13] <ggm> several attempts to point out on ML that the protos under eval used general data movers, able to take anything
[17:13] <ggm> IPDR, CRAIN, DIAMETER and are protos which are more specific, limits to extensibility. will address netflow in a minute
[17:14] <ggm> are eval criteria here which penalize protos which can't address sampling/metering issues
[17:14] <ggm> eg. one requirement, having protocols like IPDR/CRAIN marked as extensible is not totally taking into consideration they
[17:14] <ggm> dont have these things. marked not applicable. should not be a downgrade mark.
[17:14] <ggm> chair
[17:15] <ggm> don't clearly understand. want to bring this back to points or order with eval process
[17:15] <ggm> saying its apples to oranges. protos with impacts, protos with no impact
[17:15] <ggm> made comments on ML several times.
[17:16] <ggm> chair we realize we're evaluating protocols with different foci
[17:16] <ggm> chair neville specifically, asked we work together to merge protocols as done in other WG.
[17:16] <ggm> EXACT and IPDR.org decided to merge. very ahead in process. just not complete in time for this meeting, to bring
[17:17] <ggm> combined draft to meeting. was not ready, didn't think decision would be made at this time.
[17:17] <ggm> we wish this to be considered.
[17:17] <ggm> Neville
[17:17] <ggm> delighted to hear there is a cooperative effort. from an IETF perspective, if it doesnt happen on the ML it doesnt happen. its odd to have it appear on the horizon like ths
[17:17] <ggm> go back to charter and process
[17:18] <ggm> we got to the point with the spreadsheet scoring how well proto met the requirement was very hard to differentiate
[17:18] <ggm> so, it became clear to the chairs and nearly all of the eval team, the process doesn't provide as we ran it, any good way to resolve.
[17:19] <ggm> so in an attempt to do that, and I think I pointed it out on ML a week ago or so, have tried to push group and eval team into deciding
[17:19] <ggm> what is the focus. what do we want. what do we want IPFIX to do.
[17:19] <ggm> the way the charter is written, its aimed at efficient flow export from network devices. rb" want charter changed to standardize netflow he'd take to IESG" but we didn't ask for that. want sense of room: what do people here think we're trying to do?
[17:20] <ggm> if crain and idpr can get together and do things, thats good but the other two candidates are closer to what the group is about. thats my view
[17:20] <ggm> but lets hear from the mike.
[17:20] <ggm> I dont beleive its a sudden change of direction
[17:20] <ggm> kurt Q on slide. not most active follower of the group
[17:21] <ggm> kurtis linquist
[17:21] <ggm> want to use use TCP short term, but deploy on proto which are not TCP
[17:21] <ggm> chair yes but goal is to go for congestion control proto and an alg. tcp sctp and <thing>
[17:21] %% ggm has left.
[17:22] %% ggm has arrived.
[17:22] <ggm> sorry. dropout.
[17:22] <ggm> dont see that we can't start on SCTP straight away and skip TCP
[17:22] <ggm> chair agree but TCP is more ubiquitous
[17:22] <ggm> jeff myer
[17:22] <ggm> one proto I picked doesn't support TCP but thats a prime point of your choice
[17:23] <ggm> merges. I reached out, to look into it but got no feedback. quite disappointed with conclusions
[17:23] <ggm> goal WAS to standardize netflow. the one key requirement, the tiebreaker, is what the impl. putting it on differnt devices
[17:23] <ggm> that would be fine. should have been stated and quantified. was a binary matrix yes or no. had you looked more into
[17:24] <ggm> qualitative, may have had different summation. Q is this going to provide an opportunity to FIX netflow? as somebody who writes
[17:24] <ggm> on top of it, its the worst of both worlds. some of the things should be to look at shortcomings of NF
[17:24] <ggm> neville will wait for Randy
[17:24] <ggm> RB AD hat on.
[17:24] <ggm> thats originally what the IESG thought this group was going to do.
[17:25] <ggm> chair the charter is written to say standardize existing practice. nothing new there.
[17:25] <ggm> dave was in charter from beginning
[17:25] <ggm> 'is this to standardize netflow' useful vehicle to explain what we do. we as chairs didn't want it that way and what we did
[17:25] <ggm> was find out whats out there, and they are focussed on different things.
[17:26] <ggm> neville can we fix netflow.>? cisco have v9 out there. given that as a start, next steps slides are aiming to take NF and
[17:26] <ggm> develop from there
[17:26] <ggm> to RANDY with AD: why not explicit in charter
[17:27] <ggm> we're not locked in. its just kinda what we expected. not locking in etc.
[17:27] <ggm> Q why?
[17:27] <ggm> A because its out there. ops want one tool can we clean it up...
[17:27] <ggm> also saying its a nightmare and they use it.
[17:27] <ggm> nightmare of choice
[17:28] <ggm> neville not what we're trying to do. trying to proiduce something which will effectively get flow info off devices. we belive nf is a sensible starting point.
[17:28] <ggm> dave did not go to eval team with this in mind
[17:28] <ggm> RB first time I've said something as stupid as this. no interaction, no coercion. figured you'd work it out. optimizm
[17:29] <ggm> as proto adv. seems like a waste of time. does seem like a biassed process.
[17:29] <ggm> ML has other evidence. from item 6.
[17:29] <ggm> chair intent of those people who said that. randy didn't participate in that, even if he agreed
[17:30] <ggm> RB only thing I imposed is 'not accounting' -not target expansion.
[17:30] <ggm> applicability to chrging/accounting, gave notions to get something better
[17:30] <ggm> as a consumer of netflow and enabler of usage based billing, realize prohibitive costs. need simpler things in routers
[17:31] <ggm> developed CRAIN and is in 10+ manuf. switches and devices, in fabric. deployed, critiqued. paul fromriverstone has eval'd
[17:31] <ggm> RB how many sales presentations
[17:31] <ggm> seems like biassed process, lot of deficiencies, things which need to be added to make NF plausible. more than seen here
[17:31] <ggm> there was a vehicle. of the adv. which was more fruitfuil
[17:32] <ggm> we didnt change the proto because the failures are in the metering process. we make full compliance on data transport
[17:32] <ggm> there is no mode demanding unreliable
[17:33] <ggm> 5 years ago I brought a thing into the IETF which became SCTP. it doesnt look like the original. I haven't been involved in
[17:33] <ggm> your decision. but whatever you pick is going to morph. your job is to make what you decide, and make it what you want and
[17:33] <ggm> meet the requirements
[17:34] <ggm> i realize the candiates are unhappy but the reality is by the time we're done all 10 will be unhappy. its more work to do the changes
[17:34] <ggm> I did 20 drafts. its heaps of work
[17:34] <ggm> re-iterate points already made. the charter quote only reflects a little bit. we came from the other space. seems like the process is a bit shrouded
[17:35] <ggm> as an adv. for one of the four I am dissapointed. but, can we fix this or .. take NF as a starting point, its minimal, some serious issues
[17:35] <ggm> is there a willingness to change? I didn't see any offer of compromise with concepts from other drafts.
[17:35] <ggm> Chair asking WG or asking Cisco. bringing into the WG.
[17:38] <ggm> [interruption. I asked about IPR and got a good answer sorry no notes for that bit -ggm]
[17:38] <ggm> sad about no clue this was coming but got to move on.
[17:38] <ggm> I believe cisco has patent on some aspects of some stuff in NF?
[17:38] <ggm> chair if put in to IETF, its under IETF requirements
[17:38] <ggm> ok. so list of additional things which should be into NFv9
[17:39] <ggm> chair good input to next steps.
[17:39] <ggm> chair want to talk about process
[17:39] <ggm> NEXT STEPS
[17:39] <ggm> leinen eval ID draft. its out now draft-ienen-ipfix-eval-contrib-00
[17:39] <ggm> an IPFIX protocol ID be prepared
[17:40] <ggm> draw details, but not content directly from NF v9 adv. draft
[17:40] <ggm> do awaw with the adv. draft in favor of this new protocol draft, to persue to PS
[17:40] <ggm> need an editor for the protocol ID
[17:41] <ggm> IPFIX doc roadmap
[17:41] <ggm> IPFIX-ARCHITECTURE explains how ipfix works
[17:41] <ggm> IPFIX-DATAMODEL enumerate /describe flow attr
[17:41] <ggm> IPFIX-PROTOCOL describe IPFIX protocol and encodinsg
[17:41] <ggm> IPFIX-APPLICABILITY describes typical uses required for standards track
[17:42] <ggm> chair: comments on process?
[17:42] <ggm> wasnt clear. you said, take out of adv. draft and incorperate. why adv. and not base proto.
[17:42] <ggm> chair my typos in slides. I mean the draft from our advocate, which is an ID. trying to say, that doc will NOT be the ID for IPFIX
[17:43] <ggm> will have an editor which is NOT the advocate, adv. will be involved, but we lodge a new doc with new editor.
[17:43] <ggm> Q is extensibility on the table? one of the limitations in NF today. string attr, length, can't support them now. from extension how
[17:43] <ggm> do we address vendor-specific attr. doesn't have two factors. all addressed by other candidate protos. strikes me as odd you picked
[17:43] <ggm> it.
[17:44] <ggm> chair these are just comments. not expert on NF proposal.
[17:44] <ggm> I belive it can be fixed. the flat namespace is good, keeps it simple. vsa, end up generateing another IANA number. and mix them
[17:45] <ggm> avoid SNMP. ideas to hash out on ML and rev in.
[17:45] <ggm> comment on same issue.
[17:45] <ggm> separation of transport (proto doc) and data model part. good to be open to VSA/encodings in model
[17:45] <ggm> don't see a problem with vsa's
[17:46] <ggm> benoit. on tlv. thats an issue which should be solved. we should do this on ML. you have a point
[17:46] <ggm> so dave, time to discuss what we add to list of enhancements?
[17:50] <ggm> how do we do this. how do we do extensible. but can't do variable length attr, not externally distinguishable. reliability,
[17:50] <ggm> neville take to ML
[17:56] <ggm> Nev. do have consensus to go with recommendation.
[17:56] <ggm> at the point now to find doc editors for emerging IPFIX
[17:57] <ggm> current drafts have lapsed. casey hasn't replied to emails. may need editors to pick up on that.
[17:57] <ggm> please send emails to chairs
[18:00] <ggm> see how AD feel on milestones
[18:00] <ggm> next on agenda. Benoit on draft relationship to PSAMP
[18:01] <ggm> draft-quittek-psamp-ipfix-01.txt
[18:01] <ggm> started by juergen. goals
[18:01] <ggm> avoid duplication
[18:01] <ggm> increase mutual benefits
[18:01] <ggm> harmoize
[18:01] <ggm> issues overlap/complements
[18:01] <ggm> arch slides [see the draft]
[18:03] <ggm> arch differences 1
[18:03] <ggm> <missed>
[18:03] <ggm> diff 2. flow notation
[18:03] <ggm> IPFIX is per flow. PSAMP is per packet
[18:04] <ggm> but drafts discuss extra attrs
[18:04] <ggm> diff 3. transport proto requirement
[18:04] <ggm> IPFIX is over IETF approved suggesting TCP/SCTP
[18:04] <ggm> PSAMP uses app layer congestionavoidance
[18:04] <ggm> PSAMP can compute on packet. eg hash value
[18:04] <ggm> can be used as a selector. this goes one step further than IPFIX
[18:05] <ggm> conceptual diference
[18:05] <ggm> IPFIX is focussed on header only. PSAMP looks in payload.
[18:05] <ggm> privacy issues
[18:06] <ggm> harmonization. IPFIX as PSAMP reporting PROTO or PSAMP as IPFIX component?
[18:07] <ggm> feedback
[18:07] <ggm> alex: where is the config module for PSAMP.
[18:08] <ggm> benoit. by the charter, it wont go away, its the relationship, it will be part of PSAMP
[18:08] <ggm> alex: we're looking at deploying. this means feedback loop, in realtime. that block is important. can't take it away
[18:08] <ggm> benoit: no its not on the diagram, but remains in reality,.diag is about harmonization
[18:09] <ggm> <?> on slide about comparison on transport protos
[18:09] <ggm> PSAMP only has this as one possibility, not only choice. can use SCTP if its compatible. scope for harmonization
[18:09] <ggm> chair: PSAMP is tomorrow morning. worth going to if interested in harmonization
[18:10] <ggm> last presentation
[18:10] <ggm> sprint on network monitoring
[18:11] <ggm> draft-bhattacharyya-monitoring-sprint-01.txt

[18:11] <ggm> two level monitoring infrastructure being thought about
[18:11] <ggm> impl. issues
[18:12] <ggm> summary of benefits, issues, datatypes, timescales
[18:14] <ggm> tasks effect timescales. forcasting wants weeks/months/years.
[18:14] <ggm> diagnosis is much shorter
[18:17] <ggm> short term, do link tap. summarize into flows, export metrics, retain packet heads for 24h (or more)
[18:17] <ggm> long term: migrate into routers
[18:18] <ggm> call them CMON boxes.
[18:18] <ggm> per-packet processing & linespeeds. up to OC48, but faster and faster.. sampling is way to go
[18:18] <ggm> single system for many tasks
[18:18] <ggm> up-to-date routing info
[18:18] <ggm> exposion in flow table size
[18:18] <ggm> information export issues
[18:20] <ggm> design choices: key metrics, for less export bw. but more processing on CMON
[18:21] <ggm> per flow info less processing on CMON but high speed export bw. O(Mbps) for OC-48 links
[18:21] <ggm> different trade-offs possible between on-board computation and export b.w.
[18:23] <ggm> relation to IPFIX
[18:23] <ggm> sprint work fits well with ref arch. definitions etc
[18:23] <ggm> needs sophisticated control protocol
[18:23] <ggm> goal
[18:23] <ggm> build system specific to operators needs
[18:24] <ggm> feedback to IPFIX on lessons learned and new design requirements
[18:26] <ggm> cust don't complain from one flow report. in ops, customers define what matters.
[18:26] <ggm> so dataloss is ok, reliability is desireable. trying to learn.
[18:26] <ggm> http://ipmon.sprint.com/
[18:26] <ggm> ipmon@sprintlabs.com
[18:26] <ggm> end of agenda.
[18:26] <ggm> done.
[18:27] %% ggm has left.
[18:27] %% sleinen has left.
[18:28] %% ggm has arrived.
[18:28] <ggm> marshall, URL for weblog please?
[18:32] %% ggm has left.
[18:37] %% mrose has left.
[18:49] %% rapenno has arrived.
[18:51] %% rapenno has left.
[18:52] %% powersurge has arrived.
[18:52] %% powersurge has left.
[18:58] %% kurtis has left.