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

"Rahul Patel (rahulp)" <rahulp@cisco.com> Wed, 20 March 2013 16:47 UTC

Return-Path: <rahulp@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 353FA11E80D1 for <ipfix@ietfa.amsl.com>; Wed, 20 Mar 2013 09:47:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[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 Rkem3IZlDnUx for <ipfix@ietfa.amsl.com>; Wed, 20 Mar 2013 09:47:25 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DDA2E21F8C93 for <ipfix@ietf.org>; Wed, 20 Mar 2013 09:47:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16027; q=dns/txt; s=iport; t=1363798044; x=1365007644; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=CGC0+LAi3Yp1YVpA/4JHRDmTnxgtymoBiFdGRQcyTog=; b=DqIyx2nImgeYOrTT2fnaQKiqQmZsK/ZJugQ/KofPEQdNOn12toMmkJGW 052z4XxCi4apGASCztr2LbNci10JMjoyKi0TgLmigvcOhtHCbvviYL37N FywWj9URO70RAvKFaPpPpLtmgTJKR1gNuE9WaIN2kKhNM6hNvxgZDe8ld M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjIFAAbnSVGtJXHB/2dsb2JhbABDhAa4TQGIR4FPFnSCJAEBAQR5EgEIEQMBAgsdORQJCAIEDgUIiAwMwlyOXiARBwaCWWEDl3+PY4MKgig
X-IronPort-AV: E=Sophos; i="4.84,879,1355097600"; d="scan'208,217"; a="189600509"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 20 Mar 2013 16:47:24 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2KGlOYs011725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <ipfix@ietf.org>; Wed, 20 Mar 2013 16:47:24 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.147]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 11:47:24 -0500
From: "Rahul Patel (rahulp)" <rahulp@cisco.com>
To: "Benoit Claise (bclaise)" <bclaise@cisco.com>
Thread-Topic: Feedback: regarding draft-ietf-ipfix-mediation-protocol
Thread-Index: AQHOGcq3m3VkIH+yRkGa/Azkao+B1piuqPAAgAAn5YA=
Date: Wed, 20 Mar 2013 16:47:23 +0000
Message-ID: <A1EE24E3D6D8B14A92CCA1AFB88718B21845D2AE@xmb-rcd-x05.cisco.com>
In-Reply-To: <51497242.80407@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.1.120420
x-originating-ip: [10.154.209.184]
Content-Type: multipart/alternative; boundary="_000_A1EE24E3D6D8B14A92CCA1AFB88718B21845D2AExmbrcdx05ciscoc_"
MIME-Version: 1.0
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 16:47:26 -0000

Hi Benoit,

Thanks for the response.

-Rahul

From: "Benoit Claise (bclaise)" <bclaise@cisco.com<mailto:bclaise@cisco.com>>
Date: Wednesday, March 20, 2013 12:24 AM
To: Cisco Employee <rahulp@cisco.com<mailto:rahulp@cisco.com>>
Cc: "ipfix@ietf.org<mailto:ipfix@ietf.org>" <ipfix@ietf.org<mailto:ipfix@ietf.org>>
Subject: Re: Feedback: regarding draft-ietf-ipfix-mediation-protocol

Hi Rahul,

Thanks for your review.
See in line.


Few comments.


  1.  Page 8:
     *   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.
     *   Also in the example " e.g., Filtering only 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:
     *   "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)