Subject: [ipfix] IPFIX Requirement & Netflow evaluation

From: "M. ELK" <[email-masked]>
Date: Tue, 07 Jan 2003 21:12:09 +0000

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 [ ]

XXX- IPFIX Requirement

1- Obesrvation point :
    need to specify the direction  ie: is it a  for input  or output or both 
.
     certain manufaturer box is not able to do flow capturig on the output 
and this is a LIMITATION .

2-  Metering Process requirement

    A- not clear why such requirement is part of a specific protocol (crane 
,netflow ..etc) , my understanding it is a requirement on the box 
implementation
         whatever the protocol selected .
          As such when evaluating protocol all metering process requirement 
should be marked as "N/A" .

   B- Reliability [5.1]
       For  the ATM/FR switch world collecting statistics is a 
MANDATORY/MUST requirement ,never seen a switch advertising
         XX throughput in pps/cps  with statistics collection turned off .   
Unfortunatly this is not true in the router world .
       If the router is not able to collect statistics at line rate so this 
is a LIMITATION and if sampling is proposed so  by all mean it should not be
       advertised/characterised as a FEATURE  (sampling is a feature if and 
only if it is provided in addition to line rate capabilities)

      i suggest to remove the word "either" so " The metering process MUST 
be reliable ,missing reliability must be known and indicated by
      the manufacturer implementing the IPFIX protocol "

    The IPFIX WG should emphasis those points so  :
     1- could be taken seriously by the router manufacturer  .
     2- Educate the users/customer to consider such capabilities when 
selecting a box .

     while browsing the mailing list i could see no voice from  the main 
network providers ,suggest to try to reach the participation of this group .
    This will help to set/clarify what is the "MUST" ,"Should", "Optional" 
requirement .
     The discusion is mainly dominated by manufacturer and 
application_provider , Some application_provider tried to raise the issue of 
what
      the customers are  expecting still some other simply need a "simple" 
protocol ( a certain post indicated " i like XX protocl because it is simple
      to implement and take less memory"  irespective if this "simple" 
starpped version is good enough for the customers .
      This "simple" proposal is good for a customer with couple of routers 
but not at all adecate for a provider have 100+ on the backbone and
      1000's as a CE ) .

   C- sampling [5.2]
        Need to indicate that sampling feature is provided above and over  
line rate capabilities and not as a replacement  .
        At least to indicate that using sampling could reduce the scope of 
"application requiring IP flow info export " .
        ( is it exist in real word any provider charging  customer based on 
sampling data  ? . as an anology imagine a
          restaurant charging the customer based on sampling )

D- Overload behavior [5.3]
       Need to indicate that whatever reaction is selected is based on user 
selection (configuration) .
      Also to indicate that  the manufacturer should publish when such 
condition could arise (CPU load , memory size, throughput in pps  ) .

3- Information model [6.1]
    Could we add "Average Packet size" as item nbr "27" which MAY be 
collected.

    reg Mpls , their is some view within the WG that Mpls need to be 
eliminated .
   By doing this the WG is eliminated a fast majority of customer who need 
to collect flow information from P router .
   Collecting the top label and FEC is basic requirement ,we need to get 
more info . In order to keep the IPFIX requirement doc stable may be
   issue a seperate draft  reg optional Mpls requirement .
   I could thinck of the following :

   A- Owner of the top label ( LDP, RSVP-TE,Static,......other)
   B- In case of LDP top label : The FEC .
   C- In case of RSVP-TE top label :  Tunnel end points (Head and tail) and 
optionally session name
   D-extract  N'th nbr of label under the top label ( N is user 
configurable)
   E- depth of stack .
   F- action taken on recieved top label (pop ,swap ..etc)
   G- output top label

4- Data Transfer

    A- for Congestion Awarness [6.3.1] and reliability [6.3.2]
         may be it worth to highlight explicitly  :
         IPFIX protocl could have both properties as :
          i- Built-in as part of IPFIX . wher the IPFIX protocol will be 
carried directly over IP .
          ii- inherited from any L4 protocol where IPFIX will be running on 
top .

        IPFIX WG should make a statement on which approach is preferable , 
guess from other experience (LDP,BGP  ...etc) the 2nd
        approach is encouraged .

    B- Do we have to separate "Congestion Awarness"  and "Reliability" . did 
it exist  any protocol which is
          "congestion aware" but not reliable !!! or vice versa .

    C- Not clear the drivers to have "congestion aware" as a "MUST" but 
reliability as "option" .
        to me either both are "MUST" or both are "optional" .

    D-  Reg reliability .
           How the IPFIX WG consider the importance of collecting flow stat 
. is it an optional thing/"Nice To have" ?
           (just as an anolaogy consider the BGP or LDP group considering 
unreliable exchange of update ,after all it is "simpler"
             to implement and take less memory and cpu cycle  ) .
            It is indicated as "loss or reordering of packets MUST be 
indicated" : fair enough but what is the usefullness of such indication
            (packet loss) beside knowing that the IPFIX protocol is not 
working correctly and we have to look for other alternative (something is
           known from the day of deploying IPFIX  ) .

            i guess reliability requirement should be considered as "MUST" , 
For Netflow cisco already stated that SCTP will be used (in order to
           satisy "congestion awarness" requirement [6.3.1] (3.5.3.1) ) .

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 .

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 )

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 .

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 .

  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 .

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 .

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)
    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 .
    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 .

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 .

Brgds

_________________________________________________________________
MSN 8: advanced junk mail protection and 2 months FREE*. 
http://join.msn.com/?page=features/junkmail

--
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: Juergen Quittek <[email-masked]>
Date: Wed, 08 Jan 2003 00:37:51 +0100

Thanks for the detailed comments.

Here is just a quick reply to your second comment.
Replying to the others needs more time.

    Juergen

-- M. ELK wrote on 07 January 2003 21:12 +0000:
>     A- not clear why such requirement is part of a specific protocol (crane ,netflow ..etc) , my understanding it is a requirement on the box implementation
>           As such when evaluating protocol all metering process requirement should be marked as "N/A" .
>

There is a good reason, why some of the metering process requirements are
part of the evaluation: They imply communication with the collecting process.
For example: missing reliability must be indicated, or (as you discuss later
in your message) the applied sampling method mut be clearly indicated.
These indicators must be carried by the export protocol. Therefore, the
evaluation team considered these requirements to be relevant for the protocol
evaluation.

    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Mon, 20 Jan 2003 15:27:06 +0100

Hi,

Some more inline comments on the requirement draft.
Let me reply to the comment on the netflow draft in a separate email.

Regards, Benoit.

> Note :  reference to draft-claise-ipfix-eval-netflow-03.txt is between 
> ( ) , reference to draft-ietf-ipfix-reqs-07-txt is between [ ]
>
>
>         XX throughput in pps/cps  with statistics collection turned 
> off .   Unfortunatly this is not true in the router world .
>       If the router is not able to collect statistics at line rate so 
> this is a LIMITATION and if sampling is proposed so  by all mean it 
> should not be
>       advertised/characterised as a FEATURE  (sampling is a feature if 
> and only if it is provided in addition to line rate capabilities)
>
>      i suggest to remove the word "either" so " The metering process 
> MUST be reliable ,missing reliability must be known and indicated by

Let's not forget that in case of a router, the router still has to route 
packets, even if it implements IPFIX.
This is a different philisophy than for example SS7 where you can't 
bill, then you don't offer the service.

>     while browsing the mailing list i could see no voice from  the 
> main network providers ,suggest to try to reach the participation of 
> this group .
>    This will help to set/clarify what is the "MUST" ,"Should", 
> "Optional" requirement .
> application_provider , Some application_provider tried to raise the 
> issue of what
>      the customers are  expecting still some other simply need a 
> "simple" protocol ( a certain post indicated " i like XX protocl 
> because it is simple
>      This "simple" proposal is good for a customer with couple of 
> routers but not at all adecate for a provider have 100+ on the 
> backbone and
>      1000's as a CE ) .
>
>   C- sampling [5.2]
>        Need to indicate that sampling feature is provided above and 
> over  line rate capabilities and not as a replacement  . 

Isn't it covered by:
    The metering process MAY support packet sampling. If sampling is
   supported the sampling configuration MUST be well defined. The
   sampling configuration includes the sampling method and all its
   parameters.

>
>        At least to indicate that using sampling could reduce the scope 
> of "application requiring IP flow info export " . 

What would be your proposed sentence/paragraph?

>
>        ( is it exist in real word any provider charging  customer 
> based on sampling data  ? . as an anology imagine a

>       Need to indicate that whatever reaction is selected is based on 
> user selection (configuration) .

Isn't it covered by
   But in case the overload behavior induces a change of the metering
   process behavior, the overload behavior MUST be clearly defined.

>   By doing this the WG is eliminated a fast majority of customer who 
> need to collect flow information from P router .
>   Collecting the top label and FEC is basic requirement ,we need to 
> get more info . In order to keep the IPFIX requirement doc stable may be

From the last meeting minutes
No objections were raised regarding leaving the document as-is
with respect to these issues:
 - MPLS label/FEC

>   C- In case of RSVP-TE top label :  Tunnel end points (Head and tail) 
> and optionally session name

Personally, I tend to agree with you. The most information we can 
export, the better.
But anyway, the information model must be extensible so I don't think we 
must go through all the possible fields in the req. draft.

Regards, Benoit.