Re: [IPFIX] IPFIX export: SNMP versus physical Interface

Benoit Claise <bclaise@cisco.com> Tue, 26 July 2011 20:29 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 15DC111E8097 for <ipfix@ietfa.amsl.com>; Tue, 26 Jul 2011 13:29:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.48
X-Spam-Level:
X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Akoys1TUTSdI for <ipfix@ietfa.amsl.com>; Tue, 26 Jul 2011 13:29:15 -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 4C11D5E8008 for <ipfix@ietf.org>; Tue, 26 Jul 2011 13:29:15 -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 p6QKTDRU028130; Tue, 26 Jul 2011 22:29:13 +0200 (CEST)
Received: from [10.82.214.194] (rtp-vpn4-1730.cisco.com [10.82.214.194]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6QKT7oi018325; Tue, 26 Jul 2011 22:29:08 +0200 (CEST)
Message-ID: <4E2F2393.7030600@cisco.com>
Date: Tue, 26 Jul 2011 16:29:07 -0400
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Andrew Feren <andrewf@plixer.com>, ipfix@ietf.org, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
References: <4E2EB359.8070309@cisco.com> <20110726131514.GA6421@elstar.local> <4E2EBFEA.7080109@cisco.com> <4E2ED53C.6070803@plixer.com> <20110726150219.GA7287@elstar.local>
In-Reply-To: <20110726150219.GA7287@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [IPFIX] IPFIX export: SNMP versus physical Interface
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: Tue, 26 Jul 2011 20:29:16 -0000

Juergen,

> On Tue, Jul 26, 2011 at 10:54:52AM -0400, Andrew Feren wrote:
>
>>  From a collection and reporting perspective the important difference for
>> me in these two sets of definitions isn't physical vs maybe not
>> physical, but that "The value matches the value of managed object
>> 'ifIndex' as defined in RFC 2863 ..." and everything that implies for
>> elements 10/14.
>>
>> So I agree with Paul's approach.  There are situations where either
>> 10/14 or 252/253 could be used, but if RFC 2863 applies to your
>> interface use 10/14.
>>
>> Maybe rather than replacing "IP interface" with "logical or virtual
>> interface" it could just be "interface" or "network interface".
>>
>> On a related not I'm not sure the references for 252/253 need to refer
>> readers to "[RFC2863] for the definition of the ifIndex object."
> RFC2863 always applies to an ifIndex object. I fail to see the
> problem. I find the definitions of these elements rather clear as they
> are written.
I agree.
Both sets (10/14 and 252/253( are ifIndex.
The second set applies to the physical ifIndex, while the first one 
might be non-physical.
A Flow Record can contain both, and the Collector can draw the 
conclusions if the sets are different.

So I would not change the definitions.
A clarification might be welcome (even though I'm not convinced).
However, where?
- not in IANA, which specifies individual IE, and not the relation 
between them
- maybe in the RFC5102 Proposed Draft RFC

Regards, Benoit.
>
> /js
>