Subject: [ipfix] PROPOSED list of WG items for new charter

From: Nevil Brownlee <[email-masked]>
Date: Fri, 24 Mar 2006 08:02:18 +1200

Hi all:

At our IPFIX meeting yesterday we discussed the following individual
drafts:

   draft-dressler-ipfix-aggregation-02 (Juergen Quittek)
   draft-boschi-ipfix-implementation-guidelines-01 (Elisa Boschi)
   draft-boschi-ipfix-reducing-redundancy-01 (Elisa Boschi)
   draft-bclaise-ipfix-reliability-01 (Benoit Claise)
   draft-trammel-ipfix-biflow-00 (Brian Trammel)
   draft-trammel-ipfix-file-00 (Brian Trammel)
   draft-kobayashi-ipfix-concentrator-model-01 (Atsushi Kobayashi)
   draft-kobayashi-ipfix-concentrator-mib-01 (Atsushi Kobayashi)
   draft-schmoll-ipfix-testing-00 (Paul Aitken)
   draft-stephan-isp-templates-01 (Emile Stephan)

In my opinion ..

* draft-boschi-ipfix-implementation-guidelines-01 (Elisa Boschi)
* draft-schmoll-ipfix-testing-00 (Paul Aitken)
There was clear consensus that these two are nearly complete, and 
should become WG items.

* draft-boschi-ipfix-reducing-redundancy-01 (Elisa Boschi)
comes from an earlier PSAMP draft (per-packet info), and is also nearly 
complete.  It requires one new Information Elelement, 
CommonPropertiesID, but no changes to the IPFIX protocol.

* draft-kobayashi-ipfix-concentrator-mib-01 (Atsushi Kobayashi)
At the meeting, Juergen Quittek pointed out that quite a lot of
MIB development work has been done in PSAMP, and that this draft
adds some IPFIX objects to that.  Meeting consensus was that an
IPFIX MIB (to provide monitoring capability for IPFIX and PSAMP
processes) can be completed within a year.  3 people at the meeting
stated that they'd work on a MIB, and another teo volunteered to
review the drafts.

* draft-trammel-ipfix-biflow-00 (Brian Trammel)
There is [FlowCon, Sep 05] a clear need for users to create IE's
with more structure.  That would require extensions to the IPFIX Info 
Model, allowing it to be more 'multi-dimensinal;' that's clearly future 
work.  However, it would be useful to have a well-understood, simple, 
way to handle biflows now, using the
exisiting Info Model - that's what this draft addresses.

The remaining drafts all cover ongoing work by various individuals
and groups, but I think they're all in 'early stages,' i.e. they
need quite a bit more discussion and development within the IPFIX
community.

- draft-dressler-ipfix-aggregation-02 (Juergen Quittek)
- draft-kobayashi-ipfix-concentrator-model-01 (Atsushi Kobayashi)

- draft-bclaise-ipfix-reliability-01 (Benoit Claise)

- draft-stephan-isp-templates-01 (Emile Stephan)

- draft-trammel-ipfix-file-00 (Brian Trammel)

In our new charter, I propose that we take on the following as
WG items (estimated delivery times in parenthises):

1. IPFIX Implementation Guidelines draft, to be an Informational RFC
       (6 months)
2. IPFIX Testing draft, to be an Informational RFC  (6 months)
3. IPFIX MIB, to be an Informational RFC (12 months)
4  IPFIX Biflow draft, to be an Informational RFC (6 months)

Please consider this, and send your comments to the IPFIX list.
Remember, we need you feedback - if you agree with this proposal,
send a note to say so.

I'd like to reach consensus on this by 7 April 06.  Once we have that
consensus, we'll develop the new charter and discuss that on the list.

(Meanwhile, we'll be working hard to revise our current drafts, and
get them into IETF Last Call!)

Cheers, Nevil

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

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

--
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: Nevil Brownlee <[email-masked]>
Date: Fri, 24 Mar 2006 10:37:00 +1200

Hi again:

Several people have emailed to point out that I left 'reducing
redundancy' off my proposed list.  What I meant to say was ..

3. IPFIX Reducung Reduncy, to be an Informational RFC  (6 months)

4. IPFIX MIB, to be an Informational RFC (12 months)
5. IPFIX Biflow draft, to be an Informational RFC (6 months)

> Remember, we need you feedback - if you agree with this proposal,

Just a little too quick with my 'send email' button, sorry.

Cheers again, Nevil

---

From: Benoit Claise <[email-masked]>
Date: Thu, 23 Mar 2006 16:55:07 -0600

> 5. IPFIX Biflow draft, to be an Informational RFC (6 months)
I support:
    1. IPFIX Implementation Guidelines
    2. IPFIX Testing draft
    3. IPFIX Reducing Redundancy
    4. IPFIX MIB. By the way, shouldn't be standard track.
        I was trying to find whether the PSAMP MIB would be standard 
track or not, but couldn't

I have some concerns about the biflow, which proposed several solutions, 
without precisely telling which one to choose:

   1. record adjacency -> the collector  can assume the  exporter will
      always to do this.
   2. reverse counters -> yet an extra dimension in the information model
   3. multiple I.Es. -> potentially some ambiguities

Note that I don't have the perfect solution without IPFIX version 2, as 
I explained on the list

So I'm not sure we have a consensus on the approach to adopt, which was 
a requirement for the new work charter, as far as I understood.
I would consider the biflow exactly as the reliability draft: some extra 
work is required.

Regards, Benoit.

---

From: Andrew Johnson <[email-masked]>
Date: Thu, 23 Mar 2006 23:57:42 +0000

>     4. IPFIX MIB. By the way, shouldn't be standard track.

I think you mean "shouldn't it be standard track?"

I would think it would have to be standards track if we expect to
mandate anything.

> I would consider the biflow exactly as the reliability draft: some extra 

I thought we have a set of criteria for a draft to meet before being
considered for working group adoption:
  * consensus of approach
  * maturity
  * support from the WG

I agree that the biflow draft doesn't meet the first criteria yet.
When it does, and that could be quite soon, we can consider it for
WG adoption.

regards

Andrew

---

From: Nevil Brownlee <[email-masked]>
Date: Fri, 24 Mar 2006 13:47:50 +1200

>    4. IPFIX MIB. By the way, shouldn't be standard track.

Oh dear, another bungle.  MIBs have to run on lots of different
devinces, and must interoperate.  THat means they have to be
Standards-track RFCs.

Also ..

<Nevil's personal opinion>

> I have some concerns about the biflow, which proposed several 
> solutions, without precisely telling which one to choose:
> ...

In thinking about that, I assumed that the authors/editors would
go on working on it so as to arrive at a single, elegant solution.
I'd like to see something which was a viable short-term way to do
biflows without needing significant changes to the current IPFIX
protocol.  As a by-product, this work could/should provide more
input into longer-term development of the IPFIX Info Model.

</Nevil's personal opinion>

Cheers, Nevil

---

From: Paul Aitken <[email-masked]>
Date: Fri, 24 Mar 2006 01:51:04 +0000

Nevil,

In my mind, and without prejudice to any of the authors or all their 
hard work so far, the IPFIX drafts fall into three groups:

1. Mature drafts, which can be completed soon and should be targetted 
for immediate completion:

    draft-boschi-ipfix-implementation-guidelines-01
    draft-boschi-ipfix-reducing-redundancy-01
    draft-schmoll-ipfix-testing-00

    draft-kobayashi-ipfix-concentrator-mib-01
	- this should be worked under the IPFIX MIB

2. Drafts which still require some work and should be targetted for phase 2:

    draft-dressler-ipfix-aggregation-02
    draft-bclaise-ipfix-reliability-01
    draft-trammel-ipfix-biflow-00
    draft-kobayashi-ipfix-concentrator-model-01

3. Drafts whose value I'm unconvinced of:

    draft-trammel-ipfix-file-00
    draft-stephan-isp-templates-01

And later you added:

> IPFIX Reducung Reduncy, to be an Informational RFC  (6 months)

I'm happy with these.

> 4  IPFIX Biflow draft, to be an Informational RFC (6 months)

In my opinion, biflow isn't sufficiently mature to be completed in 6 
months, even if it's possible to do biflow on a single box at all. I 
would prefer to see it in a second phase.

One final point: many of these drafts call for new Information Elements.

Do you feel that the processes for requesting, reviewing and approving 
new IE's have been clearly communicated to the WG?

Cheers.
-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Nevil Brownlee <[email-masked]>
Date: Fri, 24 Mar 2006 15:38:43 +1200

Hi again Paul:

> Do you feel that the processes for requesting, reviewing and 
> approving new IE's have been clearly communicated to the WG?

Good point.  I suspect not.  Maybe you could put together a few
paragraphs of text about that and post it to the IPFIX list?

Thanks, Nevil

---

From: Brian Trammell <[email-masked]>
Date: Fri, 24 Mar 2006 01:52:32 -0600

Benoit,

On Mar 23, 2006, at 4:55 PM, Benoit Claise wrote:

> record adjacency -> the collector  can assume the  exporter will  
> always to do this.
> reverse counters -> yet an extra dimension in the information model
> multiple I.Es. -> potentially some ambiguities
> Note that I don't have the perfect solution without IPFIX version  
> 2, as I explained on the list

I believe the forthcoming -01 revision of this draft (which we are  
hoping to have out by 31 March; one week in advance of the proposed  
date of drafting the charter) will address these concerns.

1. Record Adjacency is meant _only_ as an example of why the current  
obvious approach is inadequate (efficiency, lack of explicit flow  
association). The language will be changed to clarify this point.

2. The multiple IE approach came up during review of -00; after  
further review it has been roundly rejected, and will not appear in  
the -01 revision. It was tempting to consider, but is too ambiguous  
to move forward with.

3. The reverse counter approach is the recommended one. The language  
will reflect this. We are discussing the assignment of a Private  
Enterprise Number with IANA for reverse-direction fields in order to  
mitigate the info model dimension explosion. This point (PEN vs. non- 
private IEs in the info model for reverse counters) will require some  
discussion on the list; if consensus can be reached by mid-June,  
we'll be prepared to bring a -02 draft with no major points of  
contention to Montreal.

Regards,
Brian

---

From: Brian Trammell <[email-masked]>
Date: Fri, 31 Mar 2006 09:11:53 -0500

All,

As promised, we have completed and submitted a new revision of the  
biflow draft, draft-trammell-ipfix-biflow-01. It has not yet been  
officially posted to the I-D directories; until that time, it is  
available at:

http://www.cert.org/ietf/ipfix/draft-trammell-ipfix-biflow-01.txt

Regards,
Brian

On Mar 24, 2006, at 2:52 AM, Brian Trammell wrote:

> 1. Record Adjacency is meant _only_ as an example of why the  
> current obvious approach is inadequate (efficiency, lack of  
> explicit flow association). The language will be changed to clarify  
> this point.
>
> 3. The reverse counter approach is the recommended one. The  
> language will reflect this. We are discussing the assignment of a  
> Private Enterprise Number with IANA for reverse-direction fields in  
> order to mitigate the info model dimension explosion. This point  
> (PEN vs. non-private IEs in the info model for reverse counters)  
> will require some discussion on the list; if consensus can be  
> reached by mid-June, we'll be prepared to bring a -02 draft with no  
> major points of contention to Montreal.
>
> Regards,
> Brian