Re: [IPFIX] [IANA #476592] clarify IPFIX interface information elements

Nevil Brownlee <n.brownlee@auckland.ac.nz> Fri, 29 July 2011 15:02 UTC

Return-Path: <n.brownlee@auckland.ac.nz>
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 07D6111E808C for <ipfix@ietfa.amsl.com>; Fri, 29 Jul 2011 08:02:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 Xn88WW8umT5I for <ipfix@ietfa.amsl.com>; Fri, 29 Jul 2011 08:02:50 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 68D9211E808B for <ipfix@ietf.org>; Fri, 29 Jul 2011 08:02:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1311951769; x=1343487769; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4E32CB95.5060000@auckland.ac.nz>|Date:=20 Sat,=2030=20Jul=202011=2003:02:45=20+1200|From:=20Nevil =20Brownlee=20<n.brownlee@auckland.ac.nz>|MIME-Version: =201.0|To:=20iana-prot-param-comment@iana.org|CC:=20ipfix @ietf.org|Subject:=20Re:=20[IANA=20#476592]=20clarify=20I PFIX=20interface=20information=20elements|References:=20< RT-Ticket-476592@icann.org>=20<4E2EB62D.80607@cisco.com> =20<rt-3.8.HEAD-16099-1311716419-1791.476592-9-0@icann.or g>|In-Reply-To:=20<rt-3.8.HEAD-16099-1311716419-1791.4765 92-9-0@icann.org>|Content-Transfer-Encoding:=207bit; bh=+H5XLHfO6rSoNiHpiP2VCS7wGsQCMqPRHmgK14celI0=; b=p40IKbRhLrqsuMf4uKO4J76xcT1fE8s3owPzKuoJVSrGXp2/tdAqq2KR 9WhINLSYptnewYvjMcq5e2TDNs7koi3A58uHjj9+XkTzcD9BiyRcmaCGN 8U/KioIJ2fVIftncUWXTNcX20P4lICWMYR4h2N3OCwwKtTA6VNLXqaiz5 E=;
X-IronPort-AV: E=Sophos;i="4.67,287,1309694400"; d="scan'208";a="74833583"
X-Ironport-HAT: None - $RELAY-AUTH
X-Ironport-Source: 130.129.18.191 - Outgoing - Outgoing-SSL
Received: from dhcp-12bf.meeting.ietf.org (HELO [130.129.18.191]) ([130.129.18.191]) by mx2-int.auckland.ac.nz with ESMTP; 30 Jul 2011 03:02:47 +1200
Message-ID: <4E32CB95.5060000@auckland.ac.nz>
Date: Sat, 30 Jul 2011 03:02:45 +1200
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: iana-prot-param-comment@iana.org
References: <RT-Ticket-476592@icann.org> <4E2EB62D.80607@cisco.com> <rt-3.8.HEAD-16099-1311716419-1791.476592-9-0@icann.org>
In-Reply-To: <rt-3.8.HEAD-16099-1311716419-1791.476592-9-0@icann.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] [IANA #476592] clarify IPFIX interface information elements
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: Fri, 29 Jul 2011 15:02:51 -0000

Hi Amanda:

WG consensus (on the IPFIX list) is that we should NOT make this
change.

Instead, it looks as though we should make a clarifying statement
about it, but we haven't yet reached agreement on where that statement
should appear.

Cheers, Nevil


On 27/07/11 09:40, Amanda Baber via RT wrote:
> Hi Nevil,
>
> Are you OK with these changes?
>
> thanks,
> Amanda
>
> On Tue Jul 26 12:42:44 2011, paitken@cisco.com wrote:
>> Dear IANA,
>>
>> Subject to the WG chair / expert reviewer's approval, and per the WG
>> email attached below, I propose the following four clarifications be
>> made to the IPFIX Information Elements registry at
>> http://www.iana.org/assignments/ipfix/ipfix.xml
>>
>> Note that the changes are highlighted in red for convenience, though
>> this colour is not intended to be used in the registry.
>>
>> Thanks,
>> P.
>>
>>
>> #10 ingressInterface
>>
>> OLD
>>              The index of the IP interface where packets of this Flow
>>              are being received.  The value matches the value of managed
>>              object 'ifIndex' as defined in RFC 2863.
>>              Note that ifIndex values are not assigned statically to an
>>              interface and that the interfaces may be renumbered every
>>              time the device's management system is re-initialized, as
>>              specified in RFC 2863.
>> NEW
>>              The index of the logical or virtual IP interface where
>> packets of this Flow
>>              are being received.  The value matches the value of managed
>>              object 'ifIndex' as defined in RFC 2863.
>>              Note that ifIndex values are not assigned statically to an
>>              interface and that the interfaces may be renumbered every
>>              time the device's management system is re-initialized, as
>>              specified in RFC 2863.
>> END
>>
>>
>> #14 egressInterface
>>
>> OLD
>>              The index of the IP interface where packets of
>>              this Flow are being sent.  The value matches the value of
>>              managed object 'ifIndex' as defined in RFC 2863.
>>              Note that ifIndex values are not assigned statically to an
>>              interface and that the interfaces may be renumbered every
>>              time the device's management system is re-initialized, as
>>              specified in RFC 2863.
>> NEW
>>              The index of the logical or virtual IP interface where
>> packets of
>>              this Flow are being sent.  The value matches the value of
>>              managed object 'ifIndex' as defined in RFC 2863.
>>              Note that ifIndex values are not assigned statically to an
>>              interface and that the interfaces may be renumbered every
>>              time the device's management system is re-initialized, as
>>              specified in RFC 2863.
>> END
>>
>>
>> #252 ingressPhysicalInterface
>>
>> OLD
>>             The index of a networking device's physical interface
>> (example, a
>>             switch port) where packets of this flow are being received.
>> NEW
>>             The index of a networking device's physical interface
>> (example, a
>>             switch port) where packets of this flow are being received.
>>             The value matches the value of managed object 'ifIndex' as
>> defined in RFC 2863.
>>             Note that ifIndex values are not assigned statically to an
>>             interface and that the interfaces may be renumbered every
>>             time the device's management system is re-initialized, as
>>             specified in RFC 2863.
>> END
>>
>>
>> #253 egressPhysicalInterface
>>
>> OLD
>>             The index of a networking device's physical interface
>> (example, a
>>             switch port) where packets of this flow are being sent.
>> NEW
>>             The index of a networking device's physical interface
>> (example, a
>>             switch port) where packets of this flow are being sent.
>>             The value matches the value of managed object 'ifIndex' as
>> defined in RFC 2863.
>>             Note that ifIndex values are not assigned statically to an
>>             interface and that the interfaces may be renumbered every
>>             time the device's management system is re-initialized, as
>>             specified in RFC 2863.
>> END
>>
>>
>> -------- Original Message --------
>> Subject: 	IPFIX export: SNMP versus physical Interface
>> Date: 	Tue, 26 Jul 2011 13:30:17 +0100
>> From: 	Paul Aitken<paitken@cisco.com>
>> To: 	IETF IPFIX Working Group<ipfix@ietf.org>
>>
>>
>>
>> Dear IPFIXers,
>>
>> I noticed that the definitions of fields 10 and 14, and fields 252 and
>> 253 are confusingly similar. See below.
>>
>> Cisco uses fields 10 and 14 to export the logical or virtual interface
>> (eg. SVI, tunnel), while fields 252 and 253 export the actual physical
>> interface.
>>
>> For example, if we have an SVI configured on a VLAN, the SNMP index of
>> the SVI would be exported using fields 10 and 14, while the SNMP index
>> of the physical port in that VLAN would be exported with fields 252
> and 253.
>>
>> So I propose to update fields 10 and 11 to say, "the index of the
>> logical or virtual interface ...", to contrast with 252 and 253 which
>> say, "The index of a networking device's physical interface ...".
>>
>> And I propose to add the following text (copied from 10 and 14) to 252
>> and 253, to clarify that these are also SNMP ifIndex values:
>>
>>              The value matches the value of
>>              managed object 'ifIndex' as defined in RFC 2863.
>>              Note that ifIndex values are not assigned statically to an
>>              interface and that the interfaces may be renumbered every
>>              time the device's management system is re-initialized, as
>>              specified in RFC 2863.
>>
>>
>> The existing definitions are below for reference.
>>
>> Please shout now if you disagree.
>>
>> Thanks,
>> P.
>>
>>
>> 10 ingressInterface unsigned32 identifier current
>>
>>              The index of the IP interface where packets of this Flow
>>              are being received.  The value matches the value of managed
>>              object 'ifIndex' as defined in RFC 2863.
>>              Note that ifIndex values are not assigned statically to an
>>              interface and that the interfaces may be renumbered every
>>              time the device's management system is re-initialized, as
>>              specified in RFC 2863.
>>
>>             See [RFC2863] for the definition of the
>>             ifIndex object.
>>
>>
>> 14 egressInterface unsigned32 identifier current
>>
>>              The index of the IP interface where packets of
>>              this Flow are being sent.  The value matches the value of
>>              managed object 'ifIndex' as defined in RFC 2863.
>>              Note that ifIndex values are not assigned statically to an
>>              interface and that the interfaces may be renumbered every
>>              time the device's management system is re-initialized, as
>>              specified in RFC 2863.
>>
>>             See [RFC2863] for the definition of the
>>             ifIndex object.
>>
>>
>> 252 ingressPhysicalInterface unsigned32 identifier current
>>
>>             The index of a networking device's physical interface
>> (example, a
>>             switch port) where packets of this flow are being received.
>>
>>             See [RFC2863] for the definition of the ifIndex object.
>>
>>
>> 253 egressPhysicalInterface unsigned32 identifier current
>>
>>             The index of a networking device's physical interface
>> (example, a
>>             switch port) where packets of this flow are being sent.
>>
>>             See [RFC2863] for the definition of the ifIndex object.
>>
>
>
>


-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand