Re: [ipfix] IPFIX protocol evaluation: candidate protocols

calato@riverstonenet.com Tue, 27 August 2002 16:58 UTC

Message-ID: <3D6BAD3C.F00B1B11@riverstonenet.com>
Date: Tue, 27 Aug 2002 12:47:56 -0400
From: calato@riverstonenet.com
MIME-Version: 1.0
To: Nevil Brownlee <n.brownlee@auckland.ac.nz>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] IPFIX protocol evaluation: candidate protocols
References: <1030465415.3d6ba7877fe79@hotlava.auckland.ac.nz>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Nevil Brownlee wrote:
> 
> Hello all:
> 
> So far we have advocates for five candidate protocols.  They are
> shown below as:
> 
> Protocol        Advocate         Date announced
>                      documents describing the protocol
> ..........................................................
> 
> CRANE           Kevin Zhang      18 Jul
>                      draft-kzhang-crane-protocol-04.txt
> 
> DIAMETER        Sebastian Zander  7 Aug
>                      draft-ietf-aaa-diameter-12.txt
> 
> LFAP v5.0       Paul Calato      30 Jul
>                      draft-riverstone-lfap-01.txt, and
>                      draft-riverstone-lfap-data-01.txt
> 
> NetFlow v9      Benoit Claise    18 Jul
>                      draft-bclaise-netflow-9-00.txt
> 
> Streaming IPDR  Jeff Meyer        9 Aug
>                       http://www.ipdr.org/documents/ipfix
>                       (submitted to internet-drafts, 20 Aug as
>                       draft-meyer-ipdr-streaming-00.txt)
> 
> Closing date for declaring advocates is 2 Sep 02, i.e. this
> coming Monday.  After that no more protocols will be considered
> in the IPFIX evaluation.
> 
> The IPFIX Requirements draft has only one issue for which we still
> need consensus, i.e. the reporting of in and out interfaces.
> I'd really like to get the requirements draft through last call;
> since this topic turns out to be so intertwined with implementation
> issues, we sidestep it for now, and simply leave the requirement vague.
> In other words, I suggest we just say "SHOULD report output and input
> interfaces," and leave it to the protocol advocates to say how their
> respective protocols handle such reporting.

	Here is the issue with that, the protocols mainly discuss
	exchange of data and not processing/sematnics. LFAP for example, 
	can report none, one or both. IPFIX is putting the much needed 
	semantics around the data exchange. Hopefully we can come to
	consensus shortly on this issue.
	

> 
> 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
> 
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

[ipfix] IPFIX protocol evaluation: candidate prot… Nevil Brownlee
Re: [ipfix] IPFIX protocol evaluation: candidate … calato
Re: [ipfix] IPFIX protocol evaluation: candidate … Juergen Quittek