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

Juergen Quittek <Quittek@neclab.eu> Thu, 28 July 2011 23:50 UTC

Return-Path: <Quittek@neclab.eu>
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 34AAE11E809C for <ipfix@ietfa.amsl.com>; Thu, 28 Jul 2011 16:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.326
X-Spam-Level:
X-Spam-Status: No, score=-102.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 B-CWxAbY5jFV for <ipfix@ietfa.amsl.com>; Thu, 28 Jul 2011 16:50:22 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 986965E8004 for <ipfix@ietf.org>; Thu, 28 Jul 2011 16:50:22 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0807F28000329; Fri, 29 Jul 2011 01:50:22 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgsX21LIq3or; Fri, 29 Jul 2011 01:50:21 +0200 (CEST)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id D602428000198; Fri, 29 Jul 2011 01:50:01 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.20]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Fri, 29 Jul 2011 01:50:01 +0200
From: Juergen Quittek <Quittek@neclab.eu>
To: Benoit Claise <bclaise@cisco.com>, IETF IPFIX Working Group <ipfix@ietf.org>
Thread-Topic: [IPFIX] IPFIX export: SNMP versus physical Interface
Thread-Index: AQHMTYEQUQd+KBvGBk+W+HZkzeB47g==
Date: Thu, 28 Jul 2011 23:50:01 +0000
Message-ID: <CA576B0F.1596A%quittek@neclab.eu>
In-Reply-To: <4E2F2393.7030600@cisco.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [10.7.0.92]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23BC8F4FD69FAB418D28B61570F9BC65@office.hd>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:50:23 -0000

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