Subject: RE: [ipfix] IPFIX-ARCH : Functional flow diagram.

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Thu, 12 Jun 2003 14:36:34 -0400

Ganesh,
 
  I see now that template is mentioned in the original arch document as an
abstract concept identifying the information items to be preserved when
monitoring various flows.  
 
  I'm still unclear on the separation of "rules for encoding" and "function
of packetizing data", they sound like the same thing to me.  But, maybe it
will be clearer in the overall context of the revised document.
 
Regards,
 
  Jeff Meyer

-----Original Message-----
From: Ganesh Sadasivan [mailto:[email-masked]]
Sent: Thursday, June 12, 2003 7:16 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: [email-masked]
Subject: Re: [ipfix] IPFIX-ARCH : Functional flow diagram.

Jeff, 

   The template definition in the terminology does not assume any specific
structure for control info. 
   (like TLV or AVP or such) and only mention that it defines the structure
and semantics of records. 

   I don't know how anonymization could be an example of encoding but it
could very well be. 
   Again I am not mentioning what specifically need to be done. But just
that if there are any 
   rules like that it is maintained in the Protocol. Do you think we should
not mention this? 

Thanks 
Ganesh 

"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote: 

 Ganesh,  The use of templates overall is a protocol decision, keep in mind
that other candidates, such as Diameter are not template oriented.  So, from
an architecture perspective, I guess templates should not be mentioned at
all, they are strictly an artifact of the protocol.  I don't think I follow
your point regarding the second item, "rules for encoding".  Is
anonymization an example of encoding, or simple translation of formats (e.g.
ipaddr -> string)?  In either case, this sounds more protocol'ish than
architecture.-- Jeff 

-----Original Message----- 
From: Ganesh Sadasivan [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, June 11, 2003 2:41 PM 
To: MEYER,JEFFREY D (HP-Cupertino,ex1) 
Cc: [email-masked] 
Subject: Re: [ipfix] IPFIX-ARCH : Functional flow diagram. 
 
Jeff, 

   - Regarding 
   "Picking & sending data records and corresponding templates " 
   I  separated this out because the arch. spec does not dictate the rules
for sending 
   templates & corresponding data. That is more of a protocol decision. 

   -Regarding "rules for encoding" 
   The kind of information I was thinking is if some one want to use more
refined encoding 
   Eg. If the flow collection is done on IP address, but the address itself
is encoded as 
   a "aa.bb.cc.dd" string. 
   Is this something we should be allowing to be supported (as a MAY) ? 

Thanks 
Ganesh 

"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote: 

Ganesh,   Nice diagram.  Maybe someday IETF will move beyond ASCII art...
But this is a fine example.   In the exporter block I would make a few
modifications:| || Rules for                       |  |Functions
||   | 
| ||                                 |  |- Packetize selected control   ||
| 
| || - Picking & sending data records|->|  & data information into      ||
| 
| ||    and corresponding templates  |  |  IPFIX export packet.
||...| 
| || - Timing out flows              |  |- Handle export errors         ||
| 
| || - Selecting flows for export(*) |  |- Handle timeouts & overloads  ||
| Specifically the data record and template selections are not independent.
You cannot send out a data record w/o sending a template.  There is no
reason to send a template if you will never send a data record of that form.
So, I'd merge these into one bullet point. 

  I removed the " " since the function already states "packetize control and
data into export packets".  The rules seem to imply a level of
configurability of encoding which I don't think exists.Regards,  Jeff Meyer 

-----Original Message----- 
From: Ganesh Sadasivan [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, June 11, 2003 11:58 AM 
To: [email-masked] 
Subject: [ipfix] IPFIX-ARCH : Functional flow diagram. 

Hi, 
   I want to add this figure into the architecture spec. Please go through
this send 
   send any comments/corrections. 

                    Packet(s) coming into Observation Point(s) 
                    |                                   | 
                    |                                   | 
                    v                                   v 
  +-----------------+-------------------------+   +-----+------+ 
  |           Metering Process on an          |   |            | 
  |              Observation Point            |   |            | 
  |  packet header capturing                  |   |            | 
  |         |                                 |   | Metering   | 
  |    timestamping                           |   | Process    | 
  |         |                                 |   | on an      | 
  |         v                                 |   | Observation| 
  |  +------+                                 |   | Point      | 
  |  |      |                                 |   |            | 
  |  |   sampling Si (1:1 in case of no       |   |            | 
  |  |      |          sampling)              |   |            | 
  |  | classifying Fi (NULL when No criteria) |   |            | 
  |  |      |                                 |   |            | 
  |  +------+                                 |   |            | 
  |         |                                 |   |            | 
  +---------+---------------------------------+   +-----+------+ 
            |                                           | 
          Flows (identified by observation domain)    Flows 
            +----...                                    +--------+... 
            |                                           v 
            |     +-------------------------------------+----------------+ 
            |     |             Flow Recording Process(*)                | 
            |     | +----------------------+     +------------------+    | 
            |     | | Flow data base       |<----|Provide non-flow  |    | 
            |     | | (includes flows      |     | information (Eg. |    | 
            |     | | from all obs.        |     | router state)    |    | 
            |     | | points in an obs.    |     +------------------+
|..... 
            |     | | domain)              |                             | 
            |     | |                      |     +------------------+    | 
            |     | |                      |<----|Maintain aggregate|    | 
            |     | |                      |     | statistics       |    | 
            |     | +----------------------+     +------------------+    | 
            |     +-------------------------------+----------------------+ 
            |                                     | 
            |        Flow Database (identified by observation domain) 
            |
+------------------------.... 
            v                                     v 
+-----------+-------------------------------------+-------------------------
-+ 
|           |            Export Process           |
| 
|           |                                     +----------------------...
| 
| +---------+------------------------------------------------------------+
| 
| |         v                  IPFIX Protocol                            |
| 
| |+---------------------------------+  +-------------------------------+|
| 
| || Rules for                       |  |Functions                      ||
| 
| || - Picking & sending templates   |  |- Packetize selected control   ||
| 
| || - Picking & sending data records|->|  & data information into      ||
| 
| || - Timing out flows              |  |  IPFIX export packet.
||...| 
| || - Encoding template & data      |  |- Handle export errors         ||
| 
| || - Selecting flows for export(*) |  |- Handle timeouts & overloads  ||
| 
| |+---------------------------------+  +-------------------------------+|
| 
| |                                                                      |
| 
| +-----------------------------+----------------------------------------+
| 
|                               |
| 
|
+-----------------------------------------...| 
|                     IPFIX exported packet
| 
|                               |
| 
| +-----------------------------+----------------------------------------+
| 
| |                        Transport  Protocol                           |
| 
| +-----------------------------+----------------------------------------+
| 
|                               |
| 
+-------------------------------+-------------------------------------------
-+ 
                                | 
                                v 
                        IPFIX export packet to collector. 

(*) indicates that the block is optional. 

Thanks 
Ganesh