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

From: Paul Aitken <[email-masked]>
Date: Tue, 26 Jul 2011 13:30:17 +0100

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.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jul 2011 15:15:14 +0200

On Tue, Jul 26, 2011 at 01:30:17PM +0100, Paul Aitken wrote:
> 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.
> 
> logical or virtual interface ...", to contrast with 252 and 253
> which say, "The index of a networking device's physical interface
> ...".

Not sure this is right because if I only have a physical interface and
no logical/virtual interfaces, I think I still want to report the
physical interface in fields 10 and 11, no? I am not sure why there is
actually a need to change something here.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Paul Aitken <[email-masked]>
Date: Tue, 26 Jul 2011 14:23:54 +0100

Juergen,

> actually a need to change something here.

In this case, physical == logical, so either 10/14 or 252/253 would be 
correct.

We've always used 10/14 in this case.

P.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 26 Jul 2011 09:29:30 -0400

hi Paul,

The intent is clear from your email, but the terminology here seems like it might be implementation-specific; i'd be in favor of the change but it should be clear that:

10/14 are for "interfaces" as the term is most commonly used (I'm not saying that's the right way to say it, need more coffee)

252/253 are for "physical interfaces" in the special case that the physical interface is different than the notional interface.

Speaking of this in terms of interface "virtualization" requires someone to know more about precisely what sort of virtualization...

Cheers,

Brian

On Jul 26, 2011, at 9:23 AM, Paul Aitken wrote:

> In this case, physical == logical, so either 10/14 or 252/253 would be correct.
> 
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Andrew Feren <[email-masked]>
Date: Tue, 26 Jul 2011 10:54:52 -0400

On 07/26/2011 09:23 AM, Paul Aitken 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."

-Andrew

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jul 2011 17:02:20 +0200

> 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.

/js

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 26 Jul 2011 15:25:40 +0000

Hi all,

[Writing as technical contrionbutor] I agree.

In the definition of IEs #10 and #14 we refer to RFC2863 and state that
the IE reports the ifIndex value for that interface. This still appears to
be a very good choice and I don't think we should change this. It might be
helpful using IEs #252 and #253 when reporting the physical interface is
needed where a logical one reported by #10 or #14 is located.

    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Tue, 26 Jul 2011 16:29:07 -0400

Juergen,

> problem. I find the definitions of these elements rather clear as they
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.

---

From: Andrew Feren <[email-masked]>
Date: Tue, 26 Jul 2011 19:02:36 -0400

> - maybe in the RFC5102 Proposed Draft RFC

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

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 28 Jul 2011 23:50:01 +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

---

From: Benoit Claise <[email-masked]>
Date: Thu, 28 Jul 2011 19:54:15 -0400

Juergen,

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

Regards, benoit
> On 26.07.11 16:29, "Benoit Claise"<[email-masked]>  wrote:
>
>> Juergen,
>>