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

Benoit Claise <bclaise@cisco.com> Thu, 28 July 2011 23:54 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 0917711E8104 for <ipfix@ietfa.amsl.com>; Thu, 28 Jul 2011 16:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.508
X-Spam-Level:
X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 sk8nAxS3pQID for <ipfix@ietfa.amsl.com>; Thu, 28 Jul 2011 16:54:24 -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 7033711E809C for <ipfix@ietf.org>; Thu, 28 Jul 2011 16:54:20 -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 p6SNsJHg012387; Fri, 29 Jul 2011 01:54:19 +0200 (CEST)
Received: from [10.86.247.35] ([10.86.247.35]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6SNsFbR019316; Fri, 29 Jul 2011 01:54:16 +0200 (CEST)
Message-ID: <4E31F6A7.2050407@cisco.com>
Date: Thu, 28 Jul 2011 19:54:15 -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: Juergen Quittek <Quittek@neclab.eu>
References: <CA576B0F.1596A%quittek@neclab.eu>
In-Reply-To: <CA576B0F.1596A%quittek@neclab.eu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF IPFIX Working Group <ipfix@ietf.org>
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: Thu, 28 Jul 2011 23:54:25 -0000

Juergen,

I don't want to change the IE description. See below "So I would not 
change the definitions."

Regards, benoit
> Hi Benoit,
>
> I think we cannot change the specification of an IE once it has been
> registered at IANA.
> If we do so, existing implementations based on the spec at IANA may break.
>
>      Juergen
>
>
> On 26.07.11 16:29, "Benoit Claise"<bclaise@cisco.com>  wrote:
>
>> 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
>>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix