Subject: [ipfix] IPFIX protocol evaluation: candidate protocols

From: Nevil Brownlee <[email-masked]>
Date: Wed, 28 Aug 2002 04:23:35 +1200

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.

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:[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: [email-masked]
Date: Tue, 27 Aug 2002 12:47:56 -0400

>                      documents describing the protocol

	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.

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 27 Aug 2002 19:21:29 +0200

Hi Nevil,

We (the authors of the requirements draft) just finished editing a new
version of the requirements document. Sebastian did a great job in very
carefully reviewing each sentence. His comments and comments by others lead
to 28 minor editorial changes, 12 fixed typos, and the following non-trivial
changes:

1. We moved the requirement for time synchronization (Section 5.5.) from
SHOULD to MUST and explained how this MUST can be met with little effort.
We replaced the original Section

   5.5.  Time Synchronization

       Metering processes and collecting processes SHOULD be time-
       synchronized with each other. Using NTP or GPS are possible ways of
       achieving this. However selecting a method for time synchronization
       is not in the scope of this document.

by

   5.5.  Time Synchronization

       It MUST be possible to synchronize timestamps generated by a metering
       process with Coordinated Universal Time (UTC).

       Note that the possibility of synchronizing timestamps of each single
       metering process with UTC implies the possibility of synchronizing
       timestamps generated by different metering processes.

       Note that this does not necessarily imply that timestamps generated
       by the metering process are UTC timestamps. For example, this
       requirement can be met by using local system clock values as
       timestamps and adding an additional timestamp when exporting a report
       to a collecting process. Then the collecting process can synchronize
       the timestamps by calculating the offset between UTC and the system
       clock of the metering process.

2. We moved (as suggested by Paul) in Section 6.1. the MUST attributes "input
interface" and "output interface" from MUST to SHOULD:
   "7. input interface (ifIndex)" -> "18. input interface (ifIndex)".
   "8. output interface (ifIndex)" -> "19. output interface (ifIndex)".

3. We removed in Section 6.1. the MUST attribute "13. if BGP is supported
at the observation point: BGP AS number" and instead appended to the end of
section 6.1.:
   "In addition, the exporting process MAY be able to report attributes
    related to inter-autonomous system routing of a flow, for example
    by reporting BGP Autonoumous System numbers."

4. We added another configuration requirement to Section 7.2. (as suggested
by Sebastian on the mailing list):
   "3. the reporting interval
       This requirement only applies if the exporting process supports
       reporting in regular intervals."

[For the advocates: Changes 2. and 3. imply renumbering of items in Section 6.1.
Change 4. implies renumbering of items in Section 7.2.]

Currently, we are all proof-reading the new version which we will hopefully
finish soon.

I will send a preview to the advocates, because they probably are already
heavily working on getting their drafts finished by Monday.

Cheers,

    Juergen