ipfix@conference.ietf.jabber.com - 2002/11/21

[13:21] %% mrose has arrived.
[13:40] %% ggm has arrived.
[13:40] <ggm> web site http://ipfix.doit.wisc.edu
[13:40] <ggm> Mailing list http://ipfix.doit.wisc.edu/#Mailing_List
[13:41] <ggm> Slides to be put on http://ipfix.doit.wisc.edu/IETF55/
[13:44] %% Joseph has arrived.
[13:44] <ggm> we're on. Dave Plonka doing chair
[13:45] <ggm> IRTF Measurement group (allman 2min)
[13:45] <ggm> Agenda review (5min)
[13:45] <ggm> Introduction (Nevil 5min)
[13:45] %% sleinen has arrived.
[13:45] <ggm> Consider applicability drafy as WG document
[13:45] <ggm> drafy-zseby-ipfix-applicability-00.txt
[13:49] <ggm> Review of changes (juergen)
Evaluation report
how to proceed
Eval team draft
Security considerationso

PSAM and IPFIX
WG Milestones/Highlights

[13:51] <ggm> IRTF Measurement group (allman 2min)

chartered to think about all soirts of measurement matters
research issues
aid/coord projects
asses new techniques
increase interactions

possible IRTF collaboration
explore measurement techniques before standards-ready
venue for discussing real-world experiences with IETF metrics
measurement arm to the IETF wg's gain better understanding of
how protocols work in the wild


[13:52] <ggm> imrg details posted, open group broad participation
2-3 yearly meetings, sometimes co-lo with IETF, sometimes not
http://imrg.grc.nasa.gov/imrg


[13:54] <ggm> Introduction (Nevil 5min)

rumours floating about re-charter, charter has not changed, no
need to do so now.

any new proposed standard has to support the minimal user config
ie all the things people do now, using one-way transport

strive to see that we don't make a 'base level' standard which
could prevent applications from building on top of IPFIX

version-2 is always possible. But we have to get the base level
completed first.


[13:56] <ggm> Paul
Q how do we do 3) if we don't do the other stuff now?
A not saying we can't discuss, but we have to do a base doc, and


[13:56] <ggm> its not a MUST requirement, can be MAY

[13:56] <ggm> Consider applicability draft as WG document

need to adopt as WG draft, not individual.
nevil proposes this is done, once revised. calls for nosayers...


accepted.
[13:56] %% Joseph has left.
[13:57] <ggm> Review of changes to requirements draft (juergen)

[13:58] %% Joseph has arrived.
[13:59] <ggm> now at v7 (v4 at last meeting)

sampling rate now sampling frequency
MUST guage loss flow info during export
SHOULD support failover to backup collecting process
MUST have ability for reporting ICMP type and code


[14:02] <ggm> discussion points

change must to should on last point?

renaldo if support, should be a must. if not, may or should
? make a should, reasons to hold back some info (too quiet to follow)
?2 a lot of routers don't look at the type code
davep early force on motivation is how it effects the forwarding process
if the field isn't used to make forwarding decision, then it
doesn't have to be noted. thats my rationale


[14:06] <ggm> nevil thread from few months back on list
said that if a device is USING info in packets, eg responding
to an ICMP field, then it MUST be able to report it. if its not
using the info, then SHOULD is sufficient

icmp type and result are in that category.

?3 don't make a strong nexus between forwarding decision and
status for reporting. ports don't (neccessarily) effect forwarding
decision in an unfiltered router, but I want to see them.

nevil so make it a must?

?3 would make the standard more useful


[14:08] <ggm> martin saying ICMP code is a must, goes too far. what is important
is to say that an IPFIX device claims to support ICMP then
it needs to announce at least ICMP

?2 if you can count the fields based on the packet then report
them, if you can't then there is no sense

nevil want decision

(voted/hummed) should


[14:10] <ggm> juergen adding VPN ID attr
what is this?

toby (comments on previous point) is this informational document
avoid normative in informational. this is a requirements doc
and since it states requirements, this is felt appropriate

nevil I'll do some homework


[14:11] %% mallman has arrived.
[14:11] <ggm> nevil call to AD guidance

AD sometimes do,


[14:14] <ggm> juergen exporting NATed flow (before and after)
closed last spring on this

remove section 5.8 'ignore port copy' copied datastreams
avoid measure same packet twice.
suggestion is to leave as-is

anonymisation
suggest leave as is

drop MPLS label
require meter process to be able to separate flows
by MPLS label
require ability to export MPLS label or FEC

suggest leave it as is
~


[14:15] <ggm> enable de-duplication of received records
already in since V6.


[14:15] %% mallman has left.
[14:19] <ggm> paul flow key. need requirement to map flows to keys

juergen currently the export doesn't have a requirement to
show which of the flow attrs were used to decide this
paul wants to add the requirement to distinguish the flows

there might be other means by which you know in the collector
what is the flow key. so we decided not to have it as a requirement
not obviously needed

[14:19] %% john loughney has arrived.
[14:19] <ggm> (?2 in above is paul. I finally got the name)
[14:23] <ggm> davep give us an example

paul within or across devices, reporting the field doesn;t
mean it was part of the key. need to discriminate.

davep understand packet counters, what other fields?

paul how about ASno? I may not be differentiating the flow
on anything else. o

nevil eg a vector showing which fields are part of the key

paul in netflow v9, they do something like this.

nevil MUST or SHOULD.

paul juergens point is doesn't need to be here, not needed
in proto, leave it to architecture.

nevil need to address in doc. give us text.

[14:25] <ggm> juergen reliability discussion

improve text Add optional retx of lost flow records using TCP or STCP
appl layer acks
exchange of control info from the collector, monitor
export processes and detect overload in process of exporting
discussed solution
add aditional reliability as MAY
reliable transport
appl level ACKs
add openness to reliability extensions of the proto as a MUST


[14:26] <ggm> (guys, is this of any use or is this wasted? -do you want me to keep doing this??? -ggm)
[14:26] <john loughney> please
[14:26] <ggm> okidoki. on we go then.
[14:29] <ggm> ?1 MAY seems a worry. the things which benefit are billing apps.
benefit is when transport fails, recovery mechanism. don't gain
much in reliability, don't have buffers to retain data in high end
routers

paul thats why this is a MAY. you wouldn't do this in a high-end router
and I disagree you don't get anything. aggregate records. want to
know you get the data, gets you collectors more centrally located
but you want additional reliability in the proto, not physical
closeness

davep as a participant (not chairspeak) value in two modes of reliability
both in charter (best effort congestion control) and higher levels

[14:30] <ggm> of reliability. been thinking about TCP/STCP, both have bidi, so
we have reliable bytestream, thats not being used currently. thats
where openness lies, its not required right now, but keep the
possibility open, way to move forward with what we have defined now
but not eliminate the possibility. meantime, just work on what we
have in place

[14:31] <ggm> ?5 app ACKs can remove risks of loss which reliable transport can
not deal with

?1 High aggregate flows, if you lose one of them, its not up to IPFIX
to solve that.


[14:32] <ggm> juergen I'd like to have something like this in. would like to better
work out why somebody would use this. be clear why

?6 APP ACK not a requirement just a slightly higher level of reliability
just an option alongside TCP reliable transport


[14:33] <ggm> paul change reqts have different levels of reliability, discuss in WG
what it means, what the boundarys are limited, ok with me if
its bumped up in requirements


[14:36] <ggm> davep document out for wordings. seems prudent. not going to go into
impl details in requirements doc. lets put it in as a MAY. want
a HUM worth persuing using MAY for APPl reliability

in favour of putting effort for MAY appl reliability

hum accepted

[14:36] <ggm> juergen to work on wordings. don't make it appl specific

[14:36] <ggm> davep 15 mins over.moving to eval report

[14:37] <ggm> looking for differentiators.

need advocacy documents

Security considerations need work

use of IPSEC is not enough
need IPFIX threats draft?


[14:39] <ggm> ?1 roadmaps come from the company. dilemma. is compliance used
by eval team? how do advocates report on that?

davep let renaldo do compat matrix, follow on see if we need
to change things, how to decide

[14:39] <ggm> Renaldo slide unreadable. matrix of eval draft summary

[14:42] <ggm> additional selection criteria
simplicity
template based approack
TLV based approach
extensibility

summary
none of the proto conform to reqts.
resolve open issues that might affect eval
advocates need to update drafts. 2 more rounds
then eval team

going forward
can eliminate some proto?
how to reach consensus on candidates?
what changes are required to proto?


[14:45] <ggm> ?5 good to see map. but need to see spread. but if we put
priorities on reqts, might expose issues show spread better

davep can we go over some of these in detail. we have picked
some as differntiators, now we have eval team all present
we should go through this right now.

?5 good to be on track

chuck myer. comment on IPDR. has F across the board, but it should not
be for some stuff

?5 implicit factors need to be made explicit in factors process


[14:47] <ggm> davep (as participant not chair) even the most ubiquitous of these
protocols has been modified. CRANE is mature proto with templates
maybe we can make that a requirement for the candidate

(I am not following a lot of this stuff, its dense. so take these notes with a pinch of salt)
[14:51] <ggm> not on eval team. not trying to hijack. really want to use the time
wisely, we won't see each other for a few months. all the candidates
need extenstions. if needed, has to be spelt out in docs.

?5 discussion on list about data model and export process
ability to carry any data with constraints.

?6 metering reliability. when we looked at this requirement
we asked ourselves if this is relevant for the proto or is
local issue to the meter, found that it is useful to consider
the possibility of an unreliable meter, read this requirement
it says metering process should be reliable, or if can;t be
assured then there should be ways to express the unreliability
LFAP has quantified (useful way in his opinion) when or how much
traffic could not be counted


[14:53] <ggm> davep does the E on the matrix mean the eval team aren't willing to
comment or ...

?5 just means its newo

run comment more related to metering process. is it being reliably
metered. metering endpoint more than protocol

?5 there is much discussion on ML about separating processes
export/metering. so this can make it not applicable to eval.



[14:55] <ggm> run whatever you monitor you are meant to meter it properly.

juergen requirement which relates to semantics of data, not the protocol


[14:55] %% Joseph has left.
[14:56] %% Joseph has arrived.
[15:00] <ggm> ?5 there will be no objection to explaining the issue

davep probably some communication with the eval team

the matrix needs fleshing out, so we can begin to make justified
decisions, about the candidate proto


[15:00] <ggm> paul what is the extent of change required to meet <x> may
help identify advantages of candidates

chuck T vs E. protocol purpose built for this domain of operation
get T because stuff is 'in' protocol but more general proto
which have extension mechanisms, well defined, to go from an
E to a T may just mean writing the extension stuff, may be
trivial, or changes to protocol. key distinction. E may not
be used uniformally to represent things

davep agree. need advocate to explain more, can help promote E to T,

paul don't know how to quantify, rather have explain, sometimes
trivial, sometimes difficult to make extensions. need to know

run mapping to streaming?

davep doesn't talk about it at all. stcp has a zillion modes!


[15:04] <ggm> davep you have to sell the proto to the eval team. handwaving wont
do it. strong competition. 5 protos. so advocates have to sell

chris I don't find E or Q useful. eval against docs. if docs require
then its not an E, its T. E are indications more work to be done
not eval of what protocol does

nevil not trying to standardize any of them, trying to pick best
as IPFIX proto. what we are looking for is underlying principles
so that vendors who have an existing system AND from scratch
know it can be implemented

chris so lets go to 'you support it or you dont'

nevil the more info the eval team gets, the better

paul disagree with chris. if TCP didn't exist, and had to specify
now wouldn't get us what we have now

chris I'm not saying that. I'm saying the doc should be updated
to say how to modify the proto to meet the requirements and
if they don't it fails that requirement, the advocate wont
modify the proto

paul but the COST of the change makes a difference

[15:06] <ggm>
?5 difficulty in guaging how to achieve these T's. there must
be some level of conformity which is not just boolean, we have
to make our advocacy documents true

davep without some priority the matrix isn't useful

?5 priority and degrees of compliance. need compliance too

[15:07] <ggm> this is good first order, if this differentiates. but it doesn't


davep moving forward, lets start narrowing down categories and make
advocates spell it out, if they want to continue in eval process




[15:08] <ggm>
what is considered high priority

?5 alternate proposal, narrow it down apart from tearing down each
others proto, subjective estimate of costs to change, degree of
conformity will be open to debate, rather than that have EVAL team
rate their belief, their sense of things. get larger spread that way


[15:12] <ggm> juergen against. lot of work just to get to this level. much better to
come to decision on significant issues

davep what is your recipe for coming to decision?

juergen identify requirements which are essential, take into account
additional criteria (not in these slides) then make recoomendation
not based on counting simple measures

renaldo good model.

[15:15] %% mrose has left.
[15:16] %% tbamonti has arrived.
[15:16] <ggm> ?? making decision as evaluator, useful to know about implementability
and cost to implement.

AD all of the candidates shown are draft proto, evaluating on
external behaviours known. have drafts for all of them?
we're not evaluating products

davep yep. thats it. all are on paper, at some level, so we have
to assess how viable it is.


[15:16] %% tbamonti has left.
[15:18] <ggm> juergen this is first iteration. consider what chris said, E's are
just missed requirements, we should complete document and add
explanations, give it back to advocate to see if they can make
E go to T, then do final state

AD I do not understand if the evaluators want to make them E to T
once we select one of these states, they will all become T,
the evaluators may want to assess effort, how beautiful or
spaghetti or whatever, but in the end, it HAS to be T to eb
WG document

davep trying to use proto advocates to sanity check the outcome
check that it really is a possibility. but yes, final has to be T

move on.


[15:20] <ggm> nevil before moving on, lot of work put in so far. when we started
several protocols were not documented at all in PD, now, all
produced by due date, the eval team have put a lot of work into
things, nice documents, making the comparisons, not just scoring
on T or E, but looking at what community they serve, so thankyou
to the team. now lets move on towards defning IPFIX


[15:20] %% john loughney has left.
[15:20] <ggm> huergen relationship between PSAMP and IPFIX (10mins)

[15:24] <ggm> juergen relationship between PSAMP and IPFIX (10mins)

both aim to standardize technology for
observing traffic in devices
exporting some processed part of the observation to other devices

both have packet selection as component
IPFIX one component out of many
PSAM focus on that aspect

goals
avoid duplication
increase mutual benefits between WG
harmonize standards between WGs

issues

PSAMP goals

specify selection ops for packet sampling
info to be made available for recording
describe protocols by which info is reported to apps
protos for selction/reporting config

[15:25] <ggm> what are good harmonization/leverage points?

[15:27] <ggm> PSAM has differences, include part of payload

gating function in selection process outcome is boolean decsison
to sample

issues overlap/complement/harmonziation

terminology. use same or not contradictory terminology
packet selection func.
traditionally packet filtering
sampling
packet selection model

IPFIX export for PSAMP
configuration


[15:33] <ggm>

[15:33] <ggm> nevil reworks milestone dates
[15:37] <ggm> finish.
[15:37] %% sleinen has left.
[15:38] <ggm> byeeee!
[15:38] %% ggm has left.
[15:38] %% Joseph has left.