Re: [ipfix] IPFIX protocol evaluation: candidate protocols

[Juergen Quittek <[e-mail]>]

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


--On 28 August 2002 04:23 +1200 Nevil Brownlee <[e-mail]> 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.
>
> Cheers, Nevil
>
> -----------------------------------------------------------------------
>    Nevil Brownlee                   Director, Technology Development
>    Phone: [phone] x8941      ITSS, The University of Auckland
>    FAX: [phone]      Private Bag 92019, Auckland, New Zealand
>
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
>
> --
> Help        mailto:[e-mail] and say "help" in message body
> Unsubscribe mailto:[e-mail] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/



--
Help        mailto:[e-mail] and say "help" in message body
Unsubscribe mailto:[e-mail] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/