Subject: Re: [ipfix] IPFIX Requirement & Netflow evaluation - NetFlow reply

From: Benoit Claise <[email-masked]>
Date: Mon, 03 Feb 2003 17:21:48 +0100

Hi,

[Sorry for the late reply. I haven't had much time to dedicate to IPFIX 
recently]
Thanks for the feedback.
Here are the answers to the NetFlow specific remarks.

>
> Hi
>
> Just few comments from average knowledge user
>
> Note :  reference to draft-claise-ipfix-eval-netflow-03.txt is between 
> ( ) , reference to draft-ietf-ipfix-reqs-07-txt is between [ ]
>
> YYY- For netflow evaluation
>
> 1- IP Traffic flow (3.1.1) [2.1]
>      not clear how it is Total Compliance . in netflow the flow 
> definition is fixed .
>      Their is no possibility to have function "F" to define a flow .  
> agregation schema is not user configurable (may be it is possible
>      in V9 but no documentation )  .
>     In draft-ietf-ipfix-architecture-02.txt it list 3 examples in 
> section 3 , it is not clear/documented  how netflow could implement 
> example 2 and 3 . 

Let me take the examples:

     2. one or more characteristics of the packet itself (e.g. number
        of MPLS labels, etc...)

     3. one or more of fields derived from packet treatment (e.g. next
        hop IP address, the output interface, etc...)

Regarding example 2, NetFlow MPLS aware reports information about the labels
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s24/fsmnf24.htm
Regarding example 3, NetFlow reports the IGP next hop and the output interface. 
Anyway, these are just examples. It's difficult to find a generic definition.

I don't thinkk this IP traffic flow definition mandates that the function F can be configurable on the exporting process.
Otherwise I'm sure a sentence about the subject containing a MUST/SHOULD/MAY would have been specified somewhere (for example section 4).

When you speak about the function F, I think that you refer to the section "4.  Distinguishing Flows"
And I don't think that we require a flexible configuration of flow keys in there.
We standardize the IP Flow Information Export, not the metering process.
But anyway, NetFlow can distinguish all flows by all the MUST in section 4.

Regarding the NetFlow aggregations you spoke about, that's right that the function F is not fully configurable but you can anyway choose from 11 different aggregations, which means basically eleven extra F functions.

>
>
> 2- Metering procces (3.1.3) [2.3]
>    in [2.3] their is a requirement to apply sampling and 
> classification more than once .
>   netflow metering process is not able to do this ( it could be seen 
> that the agregation feature could achieve the same outcome but this is 
> only true
>  if the user is able to define his own agregation schema and option to 
> include function "F" in the agregation definition ) 

I can understand where you deduce this requirement from:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-08.txt, section 2.3
   "The sampling function and the classifying function may be applied
   more than once with different parameters."
That's right that NetFlow doesn't allow that right now for the sampling; it does for the classification. 
But anway:
- we don't try to standardize the metering process. IPFIX stands for IP Flow Information eXport
- this is a "may" requirement 
- two sampling functions can be seen as a more complex single sampling function, that will not changed anything regarding the export protocol.
  two classification functions can been as a more complex single classification function, that will not changed anything regarding export protocol.

>
>
> 3- Application requiring IP flow information [3] (3.2)
>     For "usage based accounting" ,is it assumed that netflow running 
> on top of SCTP or it will remain over UDP .
>     If the later : so Netflow can not staisfy the need/requirement for 
> "usage based accounting " application . 

We have customers using NetFlow for usage-based billing. If you plan carefully your private Data Communication Network in terms of bandwith, it will work fine!
Anyway, UDP has discussed a long time ago and is not a valid solution, unless we 
rebuild the congestion awareness in the IPFIX protocol... I don't think 
this is a good idea. So let's forget about UDP!
Don't forget that SCTP is evaluated as transport protocol for NetFlow.

>
>
> 4-Distinguishing Flow
>
>   A-by interfaces (3.3.1) [4.1]
>    the requirement call to distinguish packet by "output interface " .
>   "egress Netflow" is only  applicable if the packet arrive from MPLS 
> enabled interface ,if the packet arrive from an IP interface it will not
>     be counted in the flow so this is a LIMITATION .
>      also ,say we are interseted to meter flow going out of interface 
> ifindex=3 : not clear how we could config netflow to do this .

What you refer is "MPLS egress netflow":
    
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120st/120st10/egress.htm
    You are correct about your limitations.
We have also "output sampled netflow":
    
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s24/12soutfl.htm
    you specify this one for an outgoing interface

Note that, even if you use normal ingress netflow, you still have the 
output ifIndex populated. So you can do the accounting per output 
ifIndex if you enabled netflow on all incoming interfaces.

Finally, don't forget that there are 2 "or" in the following sentence 
from draft-ietf-ipfix-reqs-08.txt

"4.1.  Interfaces

   The metering process MUST be able to separate flows by the incoming
   interface or by the outgoing interface or by both of them."

>
>  B- by IP header fields [4.2] (3.3.2)
>       in [4.2] separation is MUST by prefix match . (3.3.2) did not 
> addressed this point .
>       Netflow could agregate by prefix match (from the routing table ) 
> and some granuality using "minimum prefix" cmmands but still
>      their is no way a user could specify a flow based on say 10.1/16 . 

Again, nothing mandates that you must be able configure the prefix 
yourself in the metering process.
You come back to the point about the F function in the IP traffic flow 
that you would like to create yourself.
Note: you will have to wait a little bit more for NetFlow to have the 
functionality that you want.

> C- by Mpls (3.3.4) [4.4]
>      Unable to find a single cisco documentation describing this 
> fearure  so how it is Total compliance .
>       if it is supported by cisco so they need to release the 
> documentation even a draft version . 

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s24/fsmnf24.htm

>
>
> 5- Information Model [6.1] (3.5.1)
>    A- For "if protocol type is ICMP: ICMP type and code" , it is not 
> addressed in (3.5.1) 

My draft was based on the req-06
This comment was inserted in req-07.
Thanks, I will correct that. Anway we are compliant!

>
>    B- For "packet counter" ,it is defined in [6.1] as " if a packet is 
> fragmented ,each fragment is counted as an individual packet"
>    in (3.5.1) it is indicated as Total compliance , unable to find a 
> cisco doc which describe/state that fragmented packet is
>    counted in the flow . 

This is not described anywhere.
I just asked the NetFlow Developper for confirmation.
If you really want a document on the web for that, I will put it on my list of to-do-things.

>
>    C- for MPLS , unable to locate field type defined for MPLS label or 
> FEC in "Cisco IOS NetFlow V9 Flow record Format White paper" neither
>         in draft-bclaise-netflow-9-00.txt nor in 
> draft-gsadasiv-ipfix-proposal-00.txt .
>         again ,cisco need to open it's hand/disclose  ongoing 
> extention to netflow . 

See the previous about MPLS aware NetFlow.

>
>
> 6- Configuration for metering process [7.1] (3.6.1)
>     [7.1] call for "specification of flows to be metered" . (3.6.1) 
> claim Total compliance despite unable to locate cisco doc which
>     specify how a user ( in term of ios cmds ) could specify a flow . 

When defining the different aggregations, you implicitely define new flows.
Again here, I know what you are after. The flow keys configuration to 
create your own F function; I answered that one before.

Regards, Benoit.