Subject: [ipfix] Re: AD review for: draft-ietf-ipfix-architecture-09.txt

From: Nevil Brownlee <[email-masked]>
Date: Thu, 6 Apr 2006 15:20:00 +1200

Hi Bert:

It's taken me longer than I'd expected to revise the IPFIX architecture
draft - that's a tribute to your caeful and very helpful review!

I've commented on the changes inline below ..

- sect 2, under bullet observation domain
  it speaks a bout a "unique ID".
  Is that administratively unique?
  or globally unique?

  * Unique per Exporting Process (i.e. administratively unique,
    certainly not globally unique).a

- sect 5.4 last line
  s/Source ID/Domain ID/ ??
  Or should the section title be somthing about "Soutrce" ??
  I am getting a bit confused about DOmain and Source ID I guess?
  Protocol doc does indeed speak about SOurce ID.

  * Changed to Observation Domain ID (ditto for all four IPFIX drafts)

- sect 6.4 2nd para.
  How can a IPfix device count the p[ackets losts in all
  the possible problem scenarios?
  Maybe the solution is to say that it should try to count
  them and if it can, then it should report. Of it cannot count
  them, then maybe give a indication of the time period that
  packets could not be handled/seen?

  * Reowrked para to:
  In such situations, the IPFIX Device should attempt to count the
  number of packet losses that have occurred, and report them to its
  Collector(s).  If it is not possible to count losses accurately,
  e.g. when transport layer errors are detected, the IPFIX device should
  report this fact, and perhaps indicate the time period during which
  some packets might not have been observed.

- sect 8.1 last para
  I think it would be good to add a few more words on how operators
  can avoid congestion. Just keeping it in their own domain helps
  to not impact other networks, but if it is a live network with
  normal user data, then it is still problemantic. Maybe you mean that
  they should use a dedicated network for it?
  Anyway, best to elaborate somewhat I think.

  * Added:      For example, one could    use a dedicated network (or 
Ethernet link) to carry IPFIX
    traffic from Exporter to Collector.

- I suspect that the Security Considerations section will be considered
  weak by the security ADs. You may want to check with them for early
  review/comment. Early meaning right before or in parallel with IETF LC.
  For example, I am not sure that just MD5 is sufficient anymore.

  * I've emailed the Security ADs asking for some feedback, but
    haven't received any answer.  I got my Network Security people
    here at Auckland to read the Security Considerations sections
    of all the drafts they weren't able to add anything useful.

    So I've made one slight change to the 'Authentication-only' section:
       TCP with MD5 options.  becomes  TCP with 'signed packet' option
       - It seems to me that sect 11 is also Security COnsideratons, no?
  So should they be subsections of Sect 10?

  * Yes.  I've done that.

- Sect 12.1
  I think you rather want Standards Action for approval of a new IPfix
  version or template, no?

  * We chose 'Specification Required' from RFC 2434, because that
    provides the highest degree of review.  Since 'IPFIX Protocol'
    and 'IPFIX Info Model' are standards-track documents, Standards Track
    action will be needed for the new RFCs defining them, so I don't
    think the words here need changing.

  * However, I've changed the words 'template number' to 'set ID,'
    so that they line up properly with the IPFIX Protocol draft.

- page 30: Intellectual Property
  the last para can be removed. We normally do not add such a statement
  because such claims can be filed any time, even after RFC publication.

  * Deleted

admin/nites/spelling

- refernces/citation issues:
  !! Missing Reference for citation: [IPFIX-INFO]
  P008 L037:       The IPFIX information model [IPFIX-INFO] defines the 
base set of

  * Fixed

- In the abstract you should not use a citation

  * Removed the citation

- sect 1.2 last para
  I would assume that config is done by network ops staff,  regardless 
if it can be done remote or local or whatever
  the tools are.

  * Changed para to:
    Note that the IPFIX system does not provide for remote configuration
    of an IPFIX device.  Instead, implementors must provide an
    effective way to configure their IPFIX devices.

- sect 2, middle of page 5
  s/vvery/very/

  * Done

- page 6, 1st line: s/field/fields/
  3rd line add closing parethesis
  one but last line: remove 1 open parenthesis

  * Done

- page 8: s/sender Exporter/sending Exporter/ ??

  * OK

- page 9
  In exmaples you should use IP addresses 192.0.2.x/24
  as per RFC3330

  * Done, addresses mapped as follows ..
    198.18.40/24 -> 102.0.2.0/26
    198.18.23/24 -> 192.0.2.64/26
    198.18.20/24 -> 192.0.2.128/26

- last sentence on page 10.
  I do not see the difference between "<-->" and "<-->"
  I know my eyes are getting worse, but this time I suspect
  it is not caused by my eyes ;-)

  * The second used tildes instead of minuses.
    I've changed them to = signs to make it clearer.

- sect 5.1.2 last sentence
  s/Metering Process/Exporting Process/ ??

  * Yes  changed to /Exporting'

- sect 5.3.1. 2nd line
  s/is/are/

  * Done

- sect 5.5  Pls use RFC3330 IP addresses in example IP addresses

  * Done (as above)

- Sect 6.3 speaks about "ID". Is that the "Domain ID" ??

  * Yes, I've changed the text to make this clear.
    {ID, configuration domain (O1,O2), sampling algorithm, interval    
(1 in 100)}, where ID is the Observation Domain ID for the domain
    containing O1 and O2.  The Observation Domain ID uniquely identifies
    this configuration, and must be sent within the Flow Records in order
    to be able to match the right configuration control information.

- sect 10: s/IPSEC/IPsec/

  * Done

I submitted the new version, draft-ietf-ipfix-architecture-10.txt
to [email-masked], it should be up in a day or so.

Thanks again, 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: Paul Aitken <[email-masked]>
Date: Thu, 06 Apr 2006 09:29:53 +0100

Nevil,

>  some packets might not have been observed.

That sounds a bit wooly :-(

Which Information Elements will indicate this? Obviously a start and / 
or end time (if known), but also something indicating where the packet 
loss occurred, in terms that the collector can understand.

So it'd be better to define an information loss message and say "the 
IPFIX device should report this fact using an information loss message."

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

---

From: Brian Trammell <[email-masked]>
Date: Thu, 6 Apr 2006 13:16:57 -0400

Paul,

Agreed. This paragraph raises a few of additional questions:

Is it _ever_ possible to assume that a Device's estimation of packet  
loss is accurate? What is the minimum standard of "accuracy" below  
which a Device should not give such an estimate? Should the  
information loss message (which, I assume, maps to a scoped data  
record in the protocol) also include some information about how  
accurate the Device thinks the estimate, if any, may be?

- Brian

On Apr 6, 2006, at 4:29 AM, Paul Aitken wrote:

> Which Information Elements will indicate this? Obviously a start  
> and / or end time (if known), but also something indicating where  
> the packet loss occurred, in terms that the collector can understand.
>
> So it'd be better to define an information loss message and say  
> "the IPFIX device should report this fact using an information loss  
> message."
>
> Cheers.
> -- 
> Paul Aitken