[08:44:10] --- ggm has joined
[08:44:47] <ggm> http://ipfix.doit.wisc.edu/
[08:45:04] <ggm> ML: http://ipfix.doit.wisc.edu/#Mailing_List
[08:45:25] <ggm> slides at: http://ipfix.doit.wisc.edu/IETF58/
[08:45:38] <ggm> Agenda was sent to list, agenda@ietf.org 3 Nov 03.
[08:50:37] <ggm> Drafts. (45min)
[08:50:43] <ggm> arch-02 (10min)
[08:50:49] <ggm> info-01 (15 min)
[08:50:56] <ggm> protocol-01 (15)
[08:51:03] <ggm> as-01 (5 mins)
[08:51:09] <ggm> short presentations (30min)
[08:58:15] <ggm> Dave kicks off @ 9:00am.
[08:58:53] --- ggm has left: Disconnected
[09:00:14] --- ggm has joined
[09:00:39] <ggm> Administrivia.
[09:01:20] <ggm> Ju:rgen presents the requirements draft.
[09:02:10] <ggm> Nevil. draft was held up, discussed with Alison Mankin. happy to agree with anonymisation MAY be implemented, rather than MUST, but feels ipfix has gfone further than needed to take words out. that is the only remaining change
[09:02:56] <ggm> Jurgen: 20 editorial comments based on comments from Randy Presuhn.
[09:03:15] <ggm> applied changes discussed in Vienna, response to IESG reviews
[09:03:56] <ggm> comment from Alison on confidentiality. wg response, moved SHOULD to MUST in doc. had decided much of this was out of scope,
[09:04:11] <ggm> two paras discuss need.
[09:05:09] <ggm> If MUST then must have code.
[09:05:16] <ggm> [nevil need text]
[09:05:26] <ggm> comments from Steve Bellovin: two requests
[09:05:55] <ggm> one, to consider SCTP alongside TCP and UDP when distinguishing flows. added statement to SHOULD this. (inc protocol type)
[09:06:03] <ggm> Jurgen checks consensus on this
[09:06:27] <ggm> Other comment from SB. how to behave in presence of header compression. old text. not well checked? doesn't fit well.
[09:06:37] <ggm> removed from sect 4.6. objections?
[09:06:45] <ggm> [nothing said]
[09:06:53] <ggm> Dave: Architecture stuff next
[09:07:10] --- phragon has joined
[09:08:52] <ggm> Ganesh Sadasivan/Nevil Brownlee
[09:09:40] <ggm> observation domain. changed defn, too loose. now a collection of obs. points, and their corresponding metering processes. comments? [nothing]
[09:09:45] <ggm> Added three new sections.
[09:09:56] <ggm> IPFIX flow collection from special devices, special traffic and overload.
[09:10:10] <ggm> modified enconding flow control, flow data info sections.
[09:10:22] <ggm> tasks to do. sync the terminology with protocol draft
[09:10:40] <ggm> input on sections on confidentiality, anonymity and collecter redundancy
[09:11:08] <ggm> Nevil: need text! send to ML or send to authors
[09:11:22] <ggm> Dave: thought about anonymity? if we don't have a method, how do we do it?
[09:11:33] <ggm> Ganesh. broad guidelines. if done, then what is done with it.
[09:11:38] --- phragon has left
[09:11:46] <ggm> Dave: Ju:rgen on information model
[09:12:59] <ggm> Jurgen: not much progress to report. version at summer meeting was quick one, mainly rephrasing, lots of text changes in info elements descriptions, but no change in structure, no new elements. current version released in august, after meeting. problems to work on it, been busy. not working on core. list of issues compiled, simon posted comments, need to work on it. not much progress to report at this time.
[09:12:59] --- abr has joined
[09:13:07] <ggm> Dave: IPFIX protocol draft.
[09:13:57] <ggm> CHanges in V1. Terminology section (?Benoit? presents)
[09:14:22] <ggm> avoid MUST SHOULD MAY in terminology sections. moved to appropriate places in the draft.
[09:14:38] <ggm> the terminology section was too detailed. restrict to main terms, move detail to chapters.
[09:14:58] <ggm> Some sentences too detailed for this section eg flow set ids. defins moved to appropriate sections.
[09:15:10] <ggm> comments on defn order, uppercasing for defns in draft. all being done for IESG.
[09:15:53] <ggm> Comments that not sure which instance a requirement applies. added extra qualifications. to make it clear which it is meter, collecter, etc. examples
[09:16:15] <ggm> some sections clarified but meaning unchanged. eg packet layout, better examples to show IPFIX work.
[09:16:29] <ggm> Flow expiration, template management, terminology summary table worked on
[09:16:44] <ggm> all based on RFC ed feedback.
[09:17:12] <ggm> Added to template FlowSet. added types around it, to make it plain it is not just the two known instances. capable of more content
[09:17:31] <ggm> new in v01 encoding. exporter must code all fields of flowsets in network byte order.
[09:17:38] <ggm> Some consensus issues, with ? text required.
[09:17:58] <ggm> use of options templat/options data record. we think WG agrees on. ipfix sync message periodically.
[09:18:20] <ggm> with no of flows, packets/btyes sent, per observation domain. no feedback, but I think yes. Different views? [nocomment]
[09:18:37] <ggm> per template as well? nothing on list [nothing inroom] will post to ML again
[09:18:58] <ggm> Meterin process stats. packets/flows dropped at the metering process due to resource starvation etc.
[09:19:10] <ggm> please send text on this.
[09:19:23] <ggm> finally, agreed to export ID, ip addr of exporter to be sent.
[09:19:33] <ggm> More consensus issues speak now..
[09:19:59] <ggm> Have length field in export pkt header. replace count with length? one feedback, saying yes. [some yes from floor]
[09:20:46] <ggm> variable length data type encoding. email from list, consensus? not well formatted. need packet format. add options template, length FFFF after this encode specific length. discussed 6-9 months ago. need better text
[09:20:48] <ggm> Open issues
[09:21:00] <ggm> Big one is transport. will influence protocol draft.
[09:21:38] <ggm> failover section, template management. reliability state diag needed. don't need lifetimes with reliable protocol.
[09:22:04] <ggm> Other big open issue, Vendor Specific Info ELems. <presentation to come> if consensus can cut&paste into draft
[09:22:55] <ggm> Sub-second timestamps is needed. consensus. but, which precision? draft speaks of centisecond (like sysuptime)
[09:23:31] <ggm> Nevil? one or two wanted microseconds.
[09:23:38] <ggm> show of hands to see milli or micro-seconds.
[09:24:09] <ggm> Dave. did discuss precedents. NTP and UNIX time. even if app doesnt have the granularity, can source from kernel.. don't have to match, can keep it open.
[09:24:22] <ggm> Q? can we make it extensible? gig/terabit pipes
[09:25:21] <ggm> Nevil this why I pushed for NTP format. goes way beyond nanosecs precision.
[09:25:32] <ggm> Nevil avoid design on the floor. push back to list. should be simple
[09:25:53] <ggm> Benoit. do on list
[09:25:59] <ggm> Open issues con't
[09:26:29] <ggm> Extensibility. need to describe decisions to make now about reserved template ID 2-254 for future work
[09:26:34] <ggm> ?IANA registry?
[09:26:42] <ggm> Nevil yes. one solution.
[09:26:58] <ggm> Nevil need IANA considerations sections. this could be done then.
[09:27:06] <ggm> Nevil need text
[09:27:19] <ggm> Minor terminology discrepancy with arch draft. Ganesh.
[09:27:23] <ggm> Any other issues?
[09:28:28] <ggm> running out of opportunities to edit both docs in parallel
[09:28:38] <ggm> Dave. Applicability Statement Tanya
[09:29:36] <ggm> two sections. Applications, Frameworks and other protos.
[09:29:51] <ggm> Apps. covered Accounting, flow defn, useful to have connection to AAA
[09:30:21] <ggm> Security Analisys/intrusion detection. useful eg high load/flows. but no pkt contents. PSAMP can help. use IPFIX as trigger?
[09:30:32] <ggm> ANalysis closer to the export/collect processe
[09:30:45] <ggm> allow ipfix reports on incident detection, timeout etc.
[09:30:47] <ggm> Net planning
[09:30:58] <ggm> long term traces, analysis of traces from different obs. points
[09:31:11] <ggm> Traffic Eng. use for load balancing
[09:31:25] <ggm> Warehousing/Mining useful to store. input for packaging.
[09:31:40] <ggm> Traffic monitoring. good for upper level trouble shooting
[09:32:07] <ggm> QoS. quick measures of delay/loss, delay variation. PSAMP comes in. accurate timestamping useful
[09:32:19] <ggm> doesn't have to be MUST in proto for this
[09:32:27] <ggm> Relation to other Frameworks/Protocols
[09:32:41] <ggm> IPFIX/AAA. conect via AAA client, connect via app specific module (ASM)
[09:32:57] <ggm> IPFIX and RTFM. define flow. can use IPFIX
[09:33:07] <ggm> Open issues. combine apps? further apps? more details?
[09:33:32] <ggm> Relation to other proto/frameworks. -middlebox section removed. will there be separate draft?
[09:33:59] <ggm> need volunteers for IPFIX->RMON/TEWG work. IPFIX->PSAMP dynamic relation right now
[09:34:01] <ggm> more groups?
[09:35:16] <ggm> [is this ok? I missed a bit of some text from the slides, too fast! -ggm]
[09:35:43] <ggm> Dave: more groups? no. focus.
[09:36:42] <ggm> Nevil. End of the status of drafts section. As you can see from listening, we are missing lots of text.
[09:37:38] <ggm> Dave. Presentation on VSA elements Stewart Bryant. (and Ganesh)
[09:37:57] <ggm> wrote it to get IPFIX/PSAMP to do this kind of thing, beyond scope of IETF (expediency)
[09:38:10] <ggm> propose two main and two sub methods. too close to call, go do WG for input.
[09:38:34] <ggm> described in terms of template flowsets. options templates more or less identical.
[09:39:14] <ggm> first thing we can do. leave template as-is, introduce new template to introduce identifiers. for every field type, there is an identifier, or authority. two parallel sections.
[09:39:36] <ggm> STRENGTHS. compatible with v9, work so far. collector would discart unknown elems, would discard new flowset.
[09:39:49] <ggm> WEAKNESS two parallel data structs, to be made together. not clean approach.
[09:40:15] <ggm> second approach. if strict in how its done, and range used by vendors eg 50/50 split, then its redundant to say its IETF defined. compress out
[09:40:36] <ggm> of the VSA info, default would be IETF, otherwise, vendor tells.
[09:40:47] <ggm> STRENGTHS, same as before
[09:41:10] <ggm> WEAKNESS need to pre-determine up front what the ranges are, so you can find them. two types of object to parse, IETF/VSIE.
[09:41:17] <ggm> next approach
[09:41:36] <ggm> tear up template design. build new one, always has vendor ID. extended field type, fully qualified
[09:42:09] <ggm> defn is authority defining type, the type and its length.
[09:42:27] <ggm> STRENGTHS. all info carried in single template flowset. more natural approach. better design if done from scratch
[09:42:42] <ggm> WEAKNESS not backwards compatible with any collectors deployed, or netflow 9
[09:43:54] <ggm> then looked at it, and do compression on it
[09:43:57] <ggm> (ie as before)
[09:44:17] <ggm> STRENGTHS get some backwards compat, specificallty, and only in the case where only IETF recs are used. may be acceptable
[09:44:34] <ggm> WEAKNESSES two types of fieldID object, pre-define ranges problem as before
[09:45:14] <ggm> template comparison table. (can't reproduce here) explains relative size issues. puts metric on the table. mildly in favour of last solution
[09:45:42] <ggm> summary. identify 4, need to pick one. prefer compressed VI QUalified. looking for WG input before proposing text to protocol draft
[09:46:30] <ggm> Dave back compat is not strictly relevant, but probably tend to same place. No dissent? take to WG
[09:47:21] <ggm> Maurizio Molina, flow selection draft.
[09:48:22] <ggm> how to avoid exporting all flows. reduce load, traffic. or to control resource limitation. could be in recording, meter, exporter.
[09:48:31] <ggm> resource limitations may become more evident under attacks
[09:50:18] <ggm> flow selection consideration in current drafts is only for exporter. I consider meter and recording processes. try to define what info is useful for flow selection. collectors able to adjust their level of trust of received information
[09:50:53] <ggm> discarding happens after flow classification.
[09:51:28] <ggm> ACM SIGCOMM paper, Molina paper at ITC_18 discuss methods for doing intelligent flow selection
[09:52:02] <ggm> export macro flow, with simple sums on the discarded packets. #pkts #bytes, timestamp first,last
[09:52:41] <ggm> at flow recording process. may be more efficient discard existing flow rec to make room for new one. looks awkward, but studies show in some situatioons its a good choice. (molina paper at ITC-18 again)
[09:53:07] <ggm> again useful to have macro level view of discarded flows, events.
[09:53:40] <ggm> may be interesting to have info on non-exported traffic.
[09:53:59] <ggm> exporting process. could be for policy reasons, or resource limitation.
[09:54:23] <ggm> non-exported can be immediately discarded. kept in the flow recording process for later exporting
[09:56:33] <ggm> info to export. again macro-level view. explains need to generate some info which permits reconstruction of total volumes
[09:56:34] <ggm> open issues
[09:56:48] <ggm> is the defined info about flow selection sufficient/redundant?
[09:57:02] <ggm> is it feasible to describle the flow selection process?
[09:57:14] <ggm> How to export flow selection information?
[09:57:33] <ggm> is not relative to a flow, but is behaviour of a whole metering/record/export process
[09:58:14] <ggm> proto draft has suggestions able to do this. use option template rec. eg use scope field. are these currently defined types enough?
[09:59:48] <ggm> Nevil. interesting. useful. eg in netramet, almost have code to do summary flow for portscan or other types. better than exporting huge numbers of tiny flows. BUT... clearly not basic IPFIX system, as we have it in current docs. enourage continuing discussion. take something forward if we can use
[09:59:57] <ggm> existing definedfields, then worth persuing.
[10:00:30] <ggm> Dave. Discussion phase. Randall Stewart, Nevil short intro
[10:00:47] <ggm> Nevils short list.
[10:00:59] <ggm> counters vs integers. (info model)
[10:01:08] <ggm> counters allow for lost data from exporter
[10:01:17] <ggm> integers don't require collecter to keep flow stats
[10:01:23] <ggm> consensus is for INTEGERS ONLY
[10:01:35] <ggm> (counters are SNMP style)
[10:02:31] <ggm> Stewart. contender for needing counter. previous presentation suggests we need both as types in info model, allocate by function. I think integer ONLY would be a major mistake
[10:03:03] <ggm> Benoit. bytes/packets distinction too. there are different types of data here.
[10:03:28] <ggm> Nevil. for some info elems, integer fine. for some counters. (Stewart agrees)
[10:03:53] <ggm> Stewart we have text. it was rejected.
[10:04:07] <ggm> Nevil if we have text, we should use it
[10:04:42] <ggm> Ju:rgen. also support both. for each, chose one for each elem, with MUST and have other MAY.
[10:04:59] <ggm> Stewart. no, better to decide for each.
[10:05:07] <ggm> NEvil. skip timestamps, been discussed
[10:06:58] <ggm> Nevil variable sized objects, how to encode.
[10:07:23] <ggm> two issues. one is q of actual variable sjized ob eg txt string. does info elem like that make sense? no way to define. if need to, then have to be in model
[10:07:41] <ggm> Nevil URLS are one obvious instance
[10:08:06] <ggm> Nevil do we have text? Being worked on. won't go into this now
[10:10:43] <ggm> Nevil other is Variable precision. COUNTER but need compressed encoding. eg ASN.1 to carry it through IPFIX packet. prposal is to declare at max size ever used, in info model, then in template say how many bytes are being carried
[10:12:04] <ggm> Nevil. consensus for TCP, SCTP should be better fit over time.
[10:12:56] <ggm> Nevil not choosing single transport. will have sections how to map onto multiple protocols.
[10:13:28] <ggm> Randy Bush. should differentiate betwen describing various, and having one mandatory to implement
[10:13:55] <ggm> RB provides better guarantee a known proto is available
[10:14:05] <ggm> RB doesn't mean mandatory to USE.
[10:14:22] <ggm> RB congestion friendliness. endless discussion
[10:20:43] --- abr has left: Disconnected
[10:23:01] --- ggm has left: Disconnected
[10:23:13] --- ggm has joined
[10:23:27] <ggm> PR-SCTP is extension. has fallback
[10:23:52] <ggm> [network outage lost me much of the text I entered here for the preable to this, Transport Area AD input etc -ggm]
[10:24:18] <ggm> Randall. PR-SCTP will be there long before IPFIX is out the door. its safe
[10:24:40] <ggm> this is about weaning the internet of UDP
[10:24:57] <ggm> PR-SCTP is better fit for this than TCP.
[10:26:01] <ggm> HP-uX, SOlaris, Linux, BSD, WIndows available
[10:26:33] <ggm> (some early release, or being worked on)
[10:27:37] <ggm> why NOT tcp. single model. reliable, congestion aware. partial reliability has to be synthesized on top. by time to code this, you will have done above-transp. PR-SCTP. won't pass architecture measures
[10:28:30] <ggm> Q: Cisco plans?
[10:28:48] <ggm> A: implemented. not clear which train its being put into. tested at june bake-off.
[10:31:35] <ggm> Dave bad args made in favour of TCP. need to argue this properly. sockets is there, its not big changes
[10:32:17] <ggm> RB don't argue the weaknesses of particular TCP implementations
[10:32:30] <ggm> Stewart its not about that, its about microcode
[10:32:46] <ggm> Stewart TCP is harder for lightweight distributed apps
[10:33:43] <ggm> Dave. rough show of hands, 10 for mandatory SCTP, 1 for TCP. take to ML.
[10:34:37] <ggm> RB wrong Q. Q was about belief in consensus.
[10:34:48] <ggm> Dave. ok. how many for mandatory TCP ? 6
[10:34:58] <ggm> how many for SCTP 11
[10:35:09] <ggm> Dave so I say rough consensus for SCTP.
[10:35:14] <ggm> Dave take to ML
[10:35:49] <ggm> WG milestones (Nevil)
[10:35:58] <ggm> All out and done by Aug 04. clearly need to review.
[10:36:17] <ggm> Requirements is close to through IESG. that milestone can move to submit, end of this month
[10:36:34] <ggm> Eval draft, Simons, go forward as WG eval draft, submit at same time
[10:36:58] <ggm> Other 4 IPFIX drafts, need a lot of text, editing. editors job is to edit text from ML. not to write it. depend on getting text.
[10:37:15] <ggm> Realistic date for completion?
[10:37:30] <ggm> Ju:rgen shouldn't be too ambitious. much text missing.
[10:38:01] <ggm> Nevil May 04? doable ? End of May? [concur] is after Seoul meeting
[10:38:15] <ggm> Nevil will put on IPFIX work page
[10:38:22] <ggm> ends 45min early.
[10:38:42] --- ggm has left