Subject: [ipfix] IPFIX slides, minutes, etc. from IETF52

From: Dave Plonka <[email-masked]>
Date: Fri, 14 Dec 2001 15:02:37 -0600

IPFIX folks,

The slide presentations and meeting minutes (draft) are now available at:

   http://ipfix.doit.wisc.edu/IETF52/

Thanks much to the authors/presenters for submitting the slide
presentations in such a timely fashion.

Dave

P.S. Regarding the NetFlow v9 presetation and related discussion at the
meeting, this clarification was offered by Will:

   While the comment was made that V9 is independent of TCP/UDP what was mean
   to be said is that it should be able to function over TCP/UDP/SCTP etc..  
   The initial target is UDP similar to prior versions of netflow.  We did not
   mean to imply in anyway we were trying to introduce a new transport protocol
   along with the V9 export formats.

I think that many of us in the meeting took that to be the case.  If
not, here it is unequivocally.

-- 
[email-masked]  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Ganesh Sadasivan <[email-masked]>
Date: Sat, 15 Dec 2001 15:40:17 -0800

Hi,
   I want to bring up this point which I had raised on the requirement spec. at the
WG
   meeting.
   It is from slide 5 on requirements where the flow definition has been changed to
include
   "incoming or outgoing interface" as a MUST.  There are cases like
   a SP is interested in getting all the packest that go between 2 ASs. This
   does not have any strict relevance to interface. An AS can be sourced
   by Multiple interfaces  in a router. Similar would be case if somebody considers
to
   define a flow based on other packet fields like src/dst IP etc. In the general
scheme of
   flow defintion ,I do not see why  there should be a restriction to include the
interfaces
   as a MUST. Claiming this as "most of the apps need the interfaces today" is not
a
   valid argument as this model is used to serve for future apps. too.
   Therefore I request the WG to consider removing this restriction.

Thanks
Ganesh