Subject: [IPFIX] New drafts: followup from Vancouver meeting

From: Nevil Brownlee <[email-masked]>
Date: Tue, 22 Jan 2008 12:38:41 +1300

Hi all:

Over the last six weeks or so I've been busy doing other non-IPFIX
things - sorry about that, I'm back to normal mode now.

One thing I got behind on was posting minutes of the Vancouver IPFIX
meeting.  Rolf Wolter kindly took notes for us (thisnk very much for
that Rolf), I've attached them to thie email.

The Vancouver meeting discussed next steps for IPFIX, in particular,
what drafts should we adopt as WG items under the current (revised)
charter.  My summary of the notes is that

a) IPFIX File Format.  This had clear consensus, was adopted as a WG
      item, and has been published as draft-ietf-ipfix-file-00.txt

The next three drafts didn't have such clear consesnus, so they were
left for discussion on the mailing list.  Lets start that discussion 
now; each of these three drafts has people activiely supporting (and
working on them.

>>>  What I need now is at least three people who will
>>>  review them, preferably whenever they change.  If you can do that,
>>>  please email me directly; when I have three I'll announce that on
>>>  the list, and we can get each new draft published.

c) Extended types in IPFIX (Elisa Boschi)           - 
draft-boschi-ipfix-exporting-type-00.txt

b) Configuration Data Model
      - draft-muenz-ipfix-configuration-03.txt

d) IPFIX Per-Stream SCTP reporting (Benoit Claise)
      - draft-claise-ipfix-export-per-sctp-stream-02.txt

Three drafts on IPFIX Mediation were discussed
      - draft-kobayashi-ipfix-mediator-model-01.txt
      - draft-dressler-ipfix-aggregation-04.txt
      - draft-kobayashi-ipfix-large-ps-00.txt (Kobayashi Atsushi)

   The goals here are to produce two documents:
   - 'IPFIX Mediation: Problem Statement'
   - 'IPFIX Mediation: Framework'

There's clearly support to move forward on this one - let's see some
discussion on this now, please.  We need to work out how to create
the documents the charter refers to, so
  - who's going to contribute text?
  - who's going to review these drafts?
  - which of the existing drafts can text be lifted from?
  - anything else?

For this discussion, please post to the list, but mark your posts by
including  MEDIATION  in the Subject Line.

Cheers, Nevil

-----------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

-----------------------------------------------------------------------
This mail sent through University of Auckland http://www.auckland.ac.nz

_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: kobayashi atsushi <[email-masked]>
Date: Tue, 22 Jan 2008 21:56:02 +0900

Hi all,

I will revise draft "draft-kobayashi-ipfix-large-ps-00.txt" based on the
following points until next meeting. 
I would appreciate if more people post any comments in IPFIX-ML. 

- more description what data get lost
I will add more description about what data get lost along Ralf's comments.
With regard to the loss of information, there are two types. One is flow
information volume after sampling and aggregation. These parameters should
be kept at same level as far as possible, even if traffic grows.
Other is IPFIX header and observation point information. This data is
necessary to be shared in whole collection system.

- description about what is Mediator
This draft doesn't make clear definition about what is Mediator, though I 
introduce mediator in introduction section. This is based on the
feedback from Thomas Hirsch. Thank you.

- load balancing method of flow records
To cope with huge flow records, we can adopt load balancing of flow
collector. But, classification function for flow records has not defined
in IPFIX document series, yet. 

- IPFIX protocols interworking
What I call Mediator needs interworking from received IPFIX protocol to
exported IPFIX protocol. In this case, the management of observation
domain id/ template id, and the handling of "withdraw message" are
necessary to be defined. If they are not defined, final collectors might
confuse and shut down IPFIX sessions.

Best Regards,
Atsushi KOBAYASHI

On Tue, 22 Jan 2008 12:38:41 +1300

> including  MEDIATION  in the Subject Line.

--- 
Atsushi KOBAYASHI  <[email-masked]>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637

---

From: kobayashi atsushi <[email-masked]>
Date: Tue, 22 Jan 2008 21:56:02 +0900

Hi all,

Best Regards,
Atsushi KOBAYASHI

---

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 23 Jan 2008 12:46:57 +0100

Dear all,

There is already an edited version of Ralf's notes
uploaded to the Proceedings server at

    http://www3.ietf.org/proceedings/07dec/minutes/ipfix.txt

Please review this version.

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 23 Jan 2008 12:46:57 +0100

Dear all,

Thanks,

    Juergen