Re: [IPFIX] exporting VLANs in IPFIX

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:
> 
> 
> 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 protected]]
> 
> 
> 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 protected]]
> 
> 
> 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.
> 
> 
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix