Re: [IPFIX] Feedback: regarding draft-ietf-ipfix-mediation-protocol

Benoit Claise <bclaise@cisco.com> Wed, 20 March 2013 08:25 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6E921F874E for <ipfix@ietfa.amsl.com>; Wed, 20 Mar 2013 01:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.108
X-Spam-Level:
X-Spam-Status: No, score=-10.108 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjbYCFtkMOTB for <ipfix@ietfa.amsl.com>; Wed, 20 Mar 2013 01:25:35 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 94D2821F86FA for <ipfix@ietf.org>; Wed, 20 Mar 2013 01:25:34 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2K8PUKM002086 for <ipfix@ietf.org>; Wed, 20 Mar 2013 09:25:30 +0100 (CET)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2K8OxcU004430; Wed, 20 Mar 2013 09:25:05 +0100 (CET)
Message-ID: <51497242.80407@cisco.com>
Date: Wed, 20 Mar 2013 09:24:34 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Rahul Patel (rahulp)" <rahulp@cisco.com>
References: <A1EE24E3D6D8B14A92CCA1AFB88718B218449C39@xmb-rcd-x05.cisco.com>
In-Reply-To: <A1EE24E3D6D8B14A92CCA1AFB88718B218449C39@xmb-rcd-x05.cisco.com>
Content-Type: multipart/alternative; boundary="------------080308010302080702000107"
Cc: "ipfix@ietf.org" <ipfix@ietf.org>
Subject: Re: [IPFIX] Feedback: regarding draft-ietf-ipfix-mediation-protocol
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2013 08:25:36 -0000

Hi Rahul,

Thanks for your review.
See in line.
>
>
> Few comments.
>
>  1. Page 8:
>      1. The difference between "Intermediate Selection Process" and
>         "Intermediate Flow Selection Process" is not clear. Is the
>         first one selecting record purely on matching content (value
>         of the fields) in the record and the second one selecting on
>         matching attributes of the fields that are not part of the
>         record in *addition* to matching content in the record? An
>         example would help here.
>
Granted, this is difficult to understand from the definitions only. 
There is some history behind these two separate definitions. Anyway, you 
get it right from your message above.
I was thinking to add to a section 2.1 "Differences between Intermediate 
Selection Process and Intermediate Flow Selection Process" in the 
draft-ietf-ipfix-mediation-protocol draft. However, thinking about it 
some more, this section should really be done in 
draft-ietf-ipfix-flow-selection-tech-14, to avoid some more confusion.
There is already section 3. "Difference between Intermediate Flow 
Selection Process and Packet Selection". Some more text should be added 
on the difference between Intermediate Selection Process and 
Intermediate Flow Selection Process

When created, draft-ietf-ipfix-mediation-protocol will refer to that new 
section.

> 1.
>      1. Also in the example " e.g., Filteringonly records from a given
>         network to a given Collector" - Does "given network" means
>         "source-ip/source-prefix of the exporter"?.
>
It means matching the flow records to a certain prefix/AS/you-name-it, 
and exporting those matched flow records to an exporter.
See for example, section 6.1 in RFC 6183
This could be explained better in the new section in 
draft-ietf-ipfix-flow-selection-tech (See previous point)
>
> 1.
>  2. Page 13:
>      1. "Figure B" A typo? Should it be "Figure 3"?
>
Corrected.
>
> 1.
>
>
> General
>
>   * On correlation process – how to correlate, what cannot be
>     correlated, etc – is this out of scope of this draft? For example,
>     Mediator A receives metric N1 and N2 per 5-tuple from exporter X
>     and metric N3 and N4 per 5-tuple from exporter Y. Mediator A can
>     easily correlate and exporter N1, N2, N3 and N4 to another
>     collector C. If the key fields are not matching or one is subset
>     of other then data can either not be correlated or can be
>     represented in a different way. Most likely all of this out of
>     scope of this document but just wanted to check.
>
Yes, it's out of scope.
The specific techniques are described/specified in the respective drafts.

    Documents specifying the operations of specific Intermediate
    Processes cover the operation of these Processes within the IPFIX
    Mediator framework, and comply with the specifications given in this
    document; they may additionally specify the operation of the process
    independently, outside the context of an IPFIX Mediator, when this is
    appropriate.  The details of specific Intermediate Processes, when
    these have additional export specifications (e.g., metadata about the
    intermediate processing conveyed through IPFIX Options Templates),
    are each treated in their own document.  As of today, these documents
    are:

    1.  "IP Flow Anonymization Support", [RFC6235  <http://tools.ietf.org/html/rfc6235>], which describes
        Anonymization techniques for IP flow data and the export of
        Anonymized data using the IPFIX protocol.

    2.  "Flow Selection Techniques" [I-D.ietf-ipfix-flow-selection-tech  <http://tools.ietf.org/html/draft-ietf-ipfix-mediation-protocol-04#ref-I-D.ietf-ipfix-flow-selection-tech>],
        which describes the process of selecting a subset of Flows from
        all Flows observed at an Observation Point, the flow selection
        motivations, and some specific flow selection techniques.

    3.  "Exporting Aggregated Flow Data using IP Flow Information Export"
        [I-D.ietf-ipfix-a9n  <http://tools.ietf.org/html/draft-ietf-ipfix-mediation-protocol-04#ref-I-D.ietf-ipfix-a9n>] which describes Aggregated Flow export
        within the framework of IPFIX Mediators and defines an
        interoperable, implementation-independent method for Aggregated
        Flow export.

    This document specifies the IP Flow Information Export (IPFIX)
    protocol specific to Mediation, i.e. the specifications that all
    Intermediate Processes type must comply to.  Some extra
    specifications might be required per Intermediate Process type (In
    which case, the Intermediate Process specific document would cover
    those).



Note that http://tools.ietf.org/html/draft-ietf-ipfix-a9n-08 mentions 
correlation, as a special case of aggregation. However, it can be very 
complex, and mainly application specific, if we go beyond the simplest 
case. So we mentioned in section 4.2.1:

    The exact steps performed to correlate and normalize flows in this
    step are application-, implementation-, and deployment-specific, and
    will not be further specified in this document.


Regards, Benoit (as a contributor)