Subject: [IPFIX] exporting VLANs in IPFIX

From: Paul Aitken <[email-masked]>
Date: Wed, 01 Feb 2012 15:33:53 +0000

Dear all,

IANA's IPFIX registry contains some nearly-identical fields for 
exporting VLAN IDs:

58  vlanId  unsigned16  identifier  current

         The IEEE 802.1Q VLAN identifier (VID) extracted from the Tag
         Control Information field that was attached to the IP packet.
         See IEEE.802-1Q.2003.
         [RFC5102]

243  dot1qVlanId  unsigned16  identifier  current

         The value of the 12-bit VLAN Identifier portion of the Tag
         Control Information field of an Ethernet frame as described in
         section 3.5.5 of [IEEE.802-3.2005].  The structure and semantics
         within the Tag Control Information field are defined in IEEE
         P802.1Q.  In case of a QinQ frame, it represents the outer tag's
         VLAN identifier and in case of an IEEE 802.1ad frame it
         represents the Service VLAN identifier in the S-TAG Tag Control
         Information (TCI) field as described in [IEEE.802-1ad.2005].
         Units = octets
         [IEEE.802-3.2005]
         [[email-masked]]

59  postVlanId  unsigned16  identifier  current

         The definition of this Information Element is identical
         to the definition of Information Element
         'vlanId', except that it reports a
         potentially modified value caused by a middlebox
         function after the packet passed the Observation Point.
         See IEEE.802-1Q.2003.
         [RFC5102]

254  postDot1q  VlanId  unsigned16  identifier  current

         The definition of this Information Element is identical to the
         definition of Information Element 'dot1qVlanId', except that it
         reports a potentially modified value caused by a middlebox
         function after the packet passed the Observation Point.
         [IEEE.802-3.2005]
         [IEEE.802-1ad.2005]
         [[email-masked]]

The reason for requesting 243 and 254 was that in NFv9 (RFC 3954), the 
definitions of 58 and 59 were much more generic:

                                            Virtual LAN identifier
    SRC_VLAN                     58   2     associated with ingress
                                            interface

                                            Virtual LAN identifier
    DST_VLAN                     59   2     associated with egress
                                            interface

These definitions do not convey to the collector whether the observed packets had an 802.1Q vlan tag, were from a static VLAN assignment to a port, from a dynamic VLAN assignment based on user or mac, from a policy based VLAN assignment, from a tunnel termination, from an ISL tag, or from some other means.

To avoid confusion over whether to use 58 or 243, 59 or 254, and to preserve backwards compatibility, I propose that IPFIX fields 58 and 59 are reverted to their generic NFv9 definitions.

ie, any VLAN ID can be exported in 58/59, while only dot1q can be exported in 243/254.

Feedback?

Thanks,
P.

---

From: Brian Trammell <[email-masked]>
Date: Wed, 1 Feb 2012 16:35:54 +0100

Hi, Paul,

This seems like a reasonable thing to do.

Cheers,

Brian

On Feb 1, 2012, at 4:33 PM, Paul Aitken wrote:

> Dear all,
> 
> IANA's IPFIX registry contains some nearly-identical fields for exporting VLAN IDs:
> 
> 
> The reason for requesting 243 and 254 was that in NFv9 (RFC 3954), the definitions of 58 and 59 were much more generic:
> 
>                                           Virtual LAN identifier
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix