[IPFIX] exporting VLANs in IPFIX
Paul Aitken <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
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