Subject: [ipfix] ipfix-arch Section 4.2 comments

From: "Kevin Zhang" <[email-masked]>
Date: Thu, 7 Mar 2002 22:07:15 -0500

Hi All,

Please see my comments and proposals related to section 4.2 of the IPFIX architecture draft. I would like to see my proposed text included in the next architecture draft.

Thanks,

Kevin  

 4.2. IPFIX protocol

   The information that needs to be exported from the exporting device 
   can be classified into the following categories:
[kz] The IPFIX protocol support bi-directional information exchanges. I recommend change the above sentence to 
"The information that needs to be exchanged between exporting and collecting devices can be classified into the following categories" [kz] 

      1 Control Information - This includes the flow type definition,
        selection criteria for packets within the flow etc.
[kz] Using template is a key feature that proposed by both Netflow and CRANE. It will greatly improve efficiency of bandwidth consumption for data export and data processing (parsing) at devices. Templates are important control information which should be negotiated.  Propose to change the above sentence to - 
"Control Information - Control information is exchanged to facilitate correct interpretation of IP flow information.  Control information may include templates and template identifiers, flow type definition, packet selection criteria, etc. [kz]

      2 Flow record - This includes data records corresponding to
        the various observed flows at each of the observation point.
[kz] propose to change the above sentence to - 
"Flow record - This includes data records that describe some aspects of observed IP flows at the observation points of interest"[kz]
   
   IPFIX protocol at the exporting device does the following:
   
      1 Encode the control information into self-describing structures.
      2 Encode the flows measured at the exporting device into flow
        records.
[kz] propose to change the above sentence to - 
"2 Encode the flow information obtained at the exporting device into flow records" [kz]

      3 Packetize the flow records and/or control information into
        export packets.
      4 Use the underlying transport layer to send the export packets
        to the collector.
[kz] propose to add - 
"5   Support dynamical procedures to enable redundant collector configurations" and 
"6 Retransmit packets upon reception of an indication of packet loss or collecting device failure" [kz]

   IPFIX protocol at the collecting device is responsible for 
   
      1 Receive and store the control information.
      2 Decode and store the flow records using the control
        information.
[kz] propose to add - 
"3 Indicate to the exporting device of any gaps of the received flow records" and 
"4 Indicate to the exporting device of any processing and/or storage congestion at the collecting device" [kz]

[kz] below are duplicated information in the current draft, I suggest to remove it.

[----
   The information that needs to be exported from the IPFIX device can 
   be classified into the following categories: 
   
      * Control Information - This includes the flow type definition,
        selection criteria for packets within the flow etc. 
      * Flow records. 

   At the IPFIX device, the protocol functionality may be split between 
   Observation domain and exporter process. IPFIX protocol at the IPFIX 
   device does the following: 
   
      1 Encode the control information into self-describing templates. 
      2 Encode the flows measured at the exporting device into flow
        records. 
      3 Packetize the flow records and/or control information into
        export packets. 
      4 Use the underlying transport layer to send the export packets
        to the collector. 

   IPFIX protocol at the collector is responsible for 
      1 Receive and store the control information. 
      2 Decode and store the flow records using the control
        information. 
----]
ÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þwýÚ"·ü"±ÏÞvæ§vÆ²þéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ

---

From: Ganesh Sadasivan <[email-masked]>
Date: Thu, 07 Mar 2002 20:13:22 -0800

Hi Kevin,
  The general comment is to refer to
  http://ipfix.doit.wisc.edu/arch/draft-ietf-ipfix-architecture-00f.txt. This is the
  updated version. Please see inline.

> "The information that needs to be exchanged between exporting and collecting devices can be classified into the following categories" [kz]

This has been moved to section 3. Note that the control info & data  are
as defined from the exporter side.

> [kz] Using template is a key feature that proposed by both Netflow and CRANE. It will greatly improve efficiency of bandwidth consumption for data export and data processing (parsing) at devices. T…

Template negotiation & infact the whole section on negotiation is still up for discussion.

> "Control Information - Control information is exchanged to facilitate correct interpretation of IP flow information.  Control information may include templates and template identifiers, flow type d…

template includes template ids (this is more the specifics). Does the sentence
"This includes the flow type definition, selection criteria for packets within the flow."
not cover what you are telling above? Flow type definition for export transaltes to
templates.

> "Flow record - This includes data records that describe some aspects of observed IP flows at the observation points of interest"[kz]

Can you elaborate on what you mean by the above sentence? Does it mean that the
flows are measured & only subset of this information is sent across?

> "2 Encode the flow information obtained at the exporting device into flow records" [kz]

"flow information"  == {values of fields within flow}  is it the intention?
If so I guess "flows" by defintion means this.

> "5   Support dynamical procedures to enable redundant collector configurations" and

Please explain .

> "6 Retransmit packets upon reception of an indication of packet loss or collecting device failure" [kz]

This behavior is still up for discussion. Basically if the underlying transport is
reliable then IPFIX protocol is transparent to this. Just to quote from the req.
spec:
"Absence of reliability of the data transfer MUST be indicated
 covering packet loss and packet reordering.".
It does not talk about retransmission.

> "3 Indicate to the exporting device of any gaps of the received flow records" and

This is also still not discussed completly. The above statement from req. spec
holds good here also.

> "4 Indicate to the exporting device of any processing and/or storage congestion at the collecting device" [kz]

This is not in scope for IPFIX protocol.

> [kz] below are duplicated information in the current draft, I suggest to remove it.

Refer to the updated draft.It has been removed.

--
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: "Kevin Zhang" <[email-masked]>
Date: Fri, 8 Mar 2002 11:09:04 -0500

Hi Ganesh,

Please see my comments inserted, I will use -00f in the future as the reference.

Thanks,

Kevin

> -----Original Message-----
> From: majordomo listserver [mailto:[email-masked]]On Behalf
> Of Ganesh Sadasivan
> Sent: Thursday, March 07, 2002 11:13 PM
> To: [email-masked]
> Cc: Ipfix@Net. Doit. Wisc. Edu; KC' 'Norseth
> Subject: [ipfix] Re: ipfix-arch Section 4.2 comments
> 
> 
> Hi Kevin,
> > Please see my comments and proposals related to section 4.2 of 
> the IPFIX architecture draft. I would like to see my proposed 
> text included in the next architecture draft.
> >
> > Thanks,
> >
> > Kevin
> >
> >  4.2. IPFIX protocol
> >
> > [kz] The IPFIX protocol support bi-directional information 
> exchanges. I recommend change the above sentence to
> > "The information that needs to be exchanged between exporting 
> and collecting devices can be classified into the following 
> categories" [kz]
> 
> > [kz] Using template is a key feature that proposed by both 
> Netflow and CRANE. It will greatly improve efficiency of 
> bandwidth consumption for data export and data processing 
> (parsing) at devices. Templates are important control information 
> which should be negotiated.  Propose to change the above sentence to -
> 
> > "Control Information - Control information is exchanged to 
> facilitate correct interpretation of IP flow information.  
> Control information may include templates and template 
> identifiers, flow type definition, packet selection criteria, etc. [kz]
> 
Template governs how the data records are put in an IPFIX user message payload, so that only flow information needs to be exported instead of (tag, length, value) type of coding.  This allows an efficient way to export as well as processing flow information.  This concept was in three previous drafts from the design team, and I believe it is essential for IPFIX. Template negotiation allows the correct context being setup at IPFIX end-points, which should be part of control information exchanges.  

> > "Flow record - This includes data records that describe some 
> aspects of observed IP flows at the observation points of interest"[kz]
> 

Yes, only the required flow information needs to be sent to the collecting device.  Though the exporting device has the final say on what it can and wants to export. 

> If so I guess "flows" by defintion means this.
"flow information" = some property of the flow, which the exporting device wants to export. It may be a field (e.g. ip address) in a flow, or it can be derived from a flow (e.g. timestamp). 

> It does not talk about retransmission.
I am quoting our charter -  
   "Ensure that the flow export system is reliable in that it will
   minimize the likelihood of flow data being lost due to resource
   constraints in the exporter or receiver and to accurately report
   such loss if it occurs" 

All of my proposals are trying to "minimize" the likelihood of data loss, whether it happens during transmission, processing, or other factors. This applies to the comments I had below.

> > "4 Indicate to the exporting device of any processing and/or 
> storage congestion at the collecting device" [kz]
> 
> ��ޖ���[h�f���h���z�ݢ+��+��njwlk/�zZ��y��Ơy��I칻�&ޙ�����j:+v���w���"��"���v�vƲ��칻�&ފ�������,j��܀��b��m����*_�ݢ+��+��n��܆+�