Subject: [ipfix] DEAFT IPFIX WG minutes, IETF54

From: Dave Plonka <[email-masked]>
Date: Mon, 15 Jul 2002 07:37:58 -0500

IPFIX folks,
  
Please review the DRAFT minutes of the most recent meeting, below.
Please send any comments/suggestions/corrections to the list.

Thanks,
Dave

P.S.  The slide shows (and also the draft minutes) are available at:

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

Dave

----------------------------------------------------------------------

DRAFT Minutes of the IP Flow Information eXport (IPFIX) WG
IETF 54, Yokohama, Monday July 15, 2002
83 people in attendance

Reported by Dave Plonka & Nevil Brownlee (co-chairs)

The meeting agenda is available here:

   http://ipfix.doit.wisc.edu/IETF54/IETF54_IPFIX_agenda.sdd
   http://ipfix.doit.wisc.edu/IETF54/IETF54_IPFIX_agenda.ppt

as well as the slideshows here:

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

1) Nevil gave an overview of the WG charter and current status.
   In summary, we're proceeding with the protocol evaluations.
   When these are complete we will revise the architecture and data
   model documents to embody the chosen protocol.

2) We reviewed the current WG drafts:

   a) Requirements (see accompanying slides)
      Juergen Quittek 

      Regarding multicast traffic, the current draft says only that
      a compliant protocol MAY report the set of egress interfaces
      and/or the "replication factor".  It was suggested that this
      be changed to either SHOULD.

      It was observed that it would be "hard" to report multicast
      egress interfaces given some current router implementations.
      However, consensus by a hum was that a protocol SHOULD support
      these metrics.

      The next revision will be published ASAP and put to WG last
      call on the mailing list.

   b) Architecture (see accompanying slides)
      Nevil Brownlee

   c) Data Model - no changes
      Nevil Brownlee

   d) Applicability (see accompanying slides)
      Tanja Zseby

      Others were encouraged to submit text for additional sections
      of this document.

3) Nevil reported the status of the protocol evaluation.  This
   information was posted to the mailing list on 7-JUL-2002:

      http://ipfix.doit.wisc.edu/archive/1000.html

   Nevil explained that the advocacy drafts will be submitted to the
   evaluation team and will subsequently be submitted as Internet
   Drafts.  (These drafts are short-lived, working group documents
   only - not to become RFCs.)

   Discussion regarding the candidate protocols is encouraged by
   all and should take place on the public mailing list using the
   "[email-masked]" address.  This will be the official
   method to communicate with the evaluation team and/or protocol
   advocates.

   Regarding the proposed deadline for advocates to submit initial
   advocacy drafts, it was suggested to change the date to 2-SEP-2002,
   to which there were no objections by those in attendance.

Three attendees indicated that they intended to advocate specific
protocols, namely: CRANE, DIAMETER, and NetFlow v9.  Other protocols
may be forthcoming, perhaps by advocates not in attendance.

Lastly, the chairs will review the WG milestones and discuss them
with with the Area Directors.

--
$Id: minutes.txt,v 1.1 2002/07/15 12:36:34 dplonka Exp $

-- 
[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: Peram Marimuthu <[email-masked]>
Date: Mon, 15 Jul 2002 06:43:01 -0700

>       be changed to either SHOULD.

I am curious to know why the egress interface list is important for multicast.
For unicast, the egress interface tells you how your packets are being routed.
However, for multicast it just conveys the input interface's observation on
potential replications which may or may not be the complete answer.

Peram

---

From: [email-masked]
Date: Mon, 15 Jul 2002 18:56:38 -0700 (PDT)

> potential replications which may or may not be the complete answer.

If you're trying to charge users for access to a multicast feed, you
need to know whether the multicast packets are being sent out on the
interface connecting to them.

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x8941      ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand

---

From: Peram Marimuthu <[email-masked]>
Date: Tue, 16 Jul 2002 03:07:48 -0700

I am not sure if we really discussed this, hence I apologize if this is
redundant.

Flow collection on ingress is useful if we want to bill the sender of
traffic. If billing the receiver, flow collection on egress is the typical
observation point.

The replication factor on ingress can only indicate the load on the
router. Packets can get dropped on the egress interface due to several
reasons. Packets may also be duplicated and sent to the CPU of the
router if the router has joined the multicast group on a given interface.
Hence the replication factor gives an approximate sense for the load
on the network.

If you are billing the receiver and are collecting multicast entries on
a given link, then it makes sense to have a series of records for each
interface through which the packet is transmitted.

Peram