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

Andrew Feren <andrewf@plixer.com> Tue, 26 July 2011 23:02 UTC

Return-Path: <andrewf@plixer.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 ADECD21F8666 for <ipfix@ietfa.amsl.com>; Tue, 26 Jul 2011 16:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 v4hY413wH0ET for <ipfix@ietfa.amsl.com>; Tue, 26 Jul 2011 16:02:48 -0700 (PDT)
Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 0999921F857D for <ipfix@ietf.org>; Tue, 26 Jul 2011 16:02:47 -0700 (PDT)
Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 19:02:47 -0400
Message-ID: <4E2F478C.60603@plixer.com>
Date: Tue, 26 Jul 2011 19:02:36 -0400
From: Andrew Feren <andrewf@plixer.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110627 Thunderbird/7.0a1
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
References: <4E2EB359.8070309@cisco.com> <20110726131514.GA6421@elstar.local> <4E2EBFEA.7080109@cisco.com> <4E2ED53C.6070803@plixer.com> <20110726150219.GA7287@elstar.local> <4E2F2393.7030600@cisco.com>
In-Reply-To: <4E2F2393.7030600@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Jul 2011 23:02:47.0390 (UTC) FILETIME=[22B847E0:01CC4BE8]
Cc: 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: Tue, 26 Jul 2011 23:02:48 -0000

On 07/26/2011 04:29 PM, Benoit Claise 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.

Thanks.  This makes sense to me now.

Two things could have made this clearer to me when I read the docs.

1) if the IANA description of 252/253 contained similar language to what
is in the descriptions for 10/14.  Something like "The value matches the
value of a physical 'ifIndex' as defined in RFC 2863."
I know when I see one description (10/14) specify RFC 2862 and the
description for a different, but similar, element (252/253) makes no
mention of RFC 2862 it is not clear to me if the second element must be
"as defined in RFC 2862".  I start to wonder if the description is
incomplete or the reference section is a cut and paste error or something.

2) I like Benoit's suggestion of putting a description of the 
relationship between these two sets of elements somewhere.
I don't have an opinion on the right location for #2.

-Andrew