Information Elements for Data Link Layer Traffic Measurement
draft-ietf-ipfix-data-link-layer-monitoring-08

[Ballot comment]
I have no objection to the publication of this document, or the technical description of each IE. However the purpose of this document is to update or populate the IANA registry which is now the definitive repository of IPFIX IEs. Therefore for each entry there needs to be a one to one mapping between the items in the definition and the headings in the IPFIX registry. This mapping has not been provided for all items.

Also where an entry is changed, an explanation needs to be provided for why the change was made together with text addressing any backwards compatibility issues, which hopefully is a note that there is no backwards compatibility issue.

I have discussed both of these issues with the authors and the responsible AD and I am happy that they will address these concerns.

[Ballot comment]
The wording in the Acknowledgements is a little odd.
s/IPFIX members/IPFIX working group participants.

---

Section 7

Surely the more granular the data that can be reported, the greater the
risk of DoS attacks on a collection point. This document appears to
significantly increase the data that could be reported by node and so
increase the possiblitiy of congesting the collector through one
(possibly accidental) configuration event. I think you should briefly
mention this and highlight the mitigations.

[Ballot discuss]
I have no objection to the publication of this document, or the technical description of each IE. However the purpose of this document is to update or populate the IANA registry which is now the definitive repository of IPFIX IEs. Therefore for each entry there needs to be a one to one mapping between the items in the definition and the headings in the IPFIX registry. This mapping has not been provided for all items.

Also where an entry is changed, an explanation needs to be provided for why the change was made together with text addressing any backwards compatibility issues, which hopefully is a note that there is no backwards compatibility issue.

[Ballot comment]
I've a few non-blocking comments that I'd like you to consider.  Feel free to chat with me about any of them if you want to.  This is all editorial.

-- Section 1 --

  While these innovations provide flexibility, scalability, and
  mobility to an existing network architecture, it increases the
  complexity of traffic measurement due to the existence of various
  Ethernet header formats.  To cope with this, a more sophisticated
  method is required.

"they increase" the complexity.  And a more sophisticated method of what?  Traffic measurement?  Please say that: "a more sophisticated method of [whatever] is required."

  layer, e.g., Ethernet header forms.  This document describes the
  Information Elements related to data link layers that enable a more
  sophisticated traffic measurement method.

Does this document only describe "the [existing] Information Elements"?  Or does it also define new IEs?

-- Section 2.2 --

  Also, the lack of
  management scalability and flexibility: increasing the number of VMs

Make it "Another is the lack of [...]".

-- Section 3.1.2 --

      *However, when the sectionOffset field corresponding to this
      Information Element does not exist, the octets MUST be from the
      start of the data link frame.*

Take this or leave it (also in the various subsections of Section 4): What you're really saying here is that the default for sectionOffset is 0, and I think it's actually clearer if you say it that way (and, in fact, you do, in Section 3.2.2):

NEW
      * If no corresponding sectionOffset is present, an offset of
      0 is used. *
END

-- Section 3.2.2 --

      If multiple sectionOffset IEs are specified within a single
      Template, then they apply to the packet section IEs in order. ie,
      the first sectionOffset applies to the first packet section, etc.

The combination of "IE" and "ie" (which should be "i.e." (note that throughout the document)) actually seems confusing, and isn't necessary.  May I suggest this?:

NEW
      If multiple sectionOffset IEs are specified within a single
      Template, then they apply to the packet section IEs in order:
      the first sectionOffset applies to the first packet section,
      the second to the second, and so on.
END

The "less" a couple of sentences later should be "fewer".

-- Section 8 --
I suggest that you add a note to the RFC Editor, reminding them to change all the "TBDnn" notations in the document, according to the IANA allocated values.  Less likely to fall through the cracks if there's an explicit reminder.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ipfix-data-link-layer-monitoring-06.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

QUESTION: Should the new registrations come from the NFSv9 range?

NOTE: IANA needs to ask the designated experts for IPFIX Information Elements whether they've reviewed the registrations/modifications proposed in this document.


IANA understands that, upon approval of this document, the following two IANA actions will be completed.

First, in the IPFIX Information Elements registry in the IP Flow Information Export (IPFIX) Entities page at

http://www.iana.org/assignments/ipfix/

the following existing entries (243-246 and 312-317) in the Information Elements registry will be modified:

ElementID: 243
Name: dot1qVlanId
Data Type: unsigned16
Data Type Semantics: identifier
Status: current
Description: The value of the 12-bit VLAN Identifier portion of the Tag Control Information field of an Ethernet frame. The structure and semantics within the Tag Control Information field are defined in [IEEE802.1Q]. In Provider Bridged Networks, it represents the Service VLAN identifier in the S-TAG Tag Control Information (TCI) field or the Customer VLAN identifier in the C-TAG Tag Control Information (TCI) field as described in [IEEE802.1Q]. In Provider Backbone Bridged Networks, it represents the Backbone VLAN identifier in the B-TAG Tag Control Information (TCI) field as described in [IEEE802.1Q]. In a virtual link between a host system and EVB bridge, it represents the Service VLAN identifier indicating S-channel as described in [IEEE802.1Qbg]. In the case of multi-tagged frame, it represents the outer tag's VLAN identifier except for I-TAG.
Range:
References: [ RFC-to-be ]

ElementID: 244
Name: dot1qPriority
Data Type: unsigned8
Data Type Semantics: identifier
Status: current
Description: The value of the 3-bit User Priority portion of the Tag Control Information field of an Ethernet frame. The structure and semantics within the Tag Control Information field are defined in [IEEE802.1Q]. In the case of multi-tagged frame, it represents the 3-bit Priority Code Point (PCP) portion of the outer tag's Tag Control Information (TCI) field as described in [IEEE802.1Q] except for I-TAG.
Range:
References: [ RFC-to-be ]

ElementID: 245
Name: dot1qCustomerVlanId
Data Type: unsigned16
Data Type Semantics: identifier
Status: current
Description: The value represents the Customer VLAN identifier in the C-TAG Tag Control Information (TCI) field as described in [IEEE802.1Q].
Range:
References: [ RFC-to-be ]

ElementID: 246
Name: dot1qCustomerPriority
Data Type: unsigned8
Data Type Semantics: identifier
Status: current
Description: The value represents the 3-bit Priority Code Point (PCP) portion of the C-TAG Tag Control Information (TCI) field as described in [IEEE802.1Q].
Range:
References: [ RFC-to-be ]

ElementID: 312
Name: dataLinkFrameSize
Data Type: unsigned16
Data Type Semantics: quantity
Status: current
Description: This Information Element specifies the length of the selected data link frame. The data link layer is defined in [ISO_IEC.7498-1_1994].
Range:
References: [ RFC-to-be ]

ElementID: 313
Name: ipHeaderPacketSection
Data Type: octetArray
Data Type Semantics:
Status: current
Description: This Information Element carries a series of n octets from the IP header of a sampled packet, starting sectionOffset octets into the IP header. However, when the sectionOffset field corresponding to this Information Element does not exist, the octets MUST be from the start of the IP header. With sufficient length, this element also reports octets from the IP payload, subject to [RFC2804]. See the Security Considerations section in [RFC5477]. The sectionExportedOctets expresses how much data was exported, while the remainder is padding. When the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or MAY have a variable length. When the sectionExportedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded. In this case, the size of the exported section may be constrained due to li
mitations in the IPFIX protocol.
Range:
References: [ RFC-to-be ]

ElementID: 314
Name: ipPayloadPacketSection
Data Type: octetArray
Data Type Semantics:
Status: current
Description: This Information Element carries a series of n octets from the IP payload of a sampled packet, starting sectionOffset octets into the IP payload. However, when the sectionOffset field corresponding to this Information Element does not exist, the octets MUST be from the start of the IP payload. The IPv4 payload is that part of the packet that follows the IPv4 header and any options, which [RFC0791] refers to as "data" or "data octets". For example, see the examples in [RFC0791], Appendix A. The IPv6 payload is the rest of the packet following the 40-octet IPv6 header. Note that any extension headers present are considered part of the payload. See [RFC2460] for the IPv6 specification. The sectionExportedOctets expresses how much data was observed, while the remainder is padding. When the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or MAY have a variable length. Whe
n the sectionExportedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded. In this case, the size of the exported section may be constrained due to limitations in the IPFIX protocol.
Range:
References: [ RFC-to-be ]

ElementID: 315
Name: dataLinkFrameSection
Data Type: octetArray
Data Type Semantics:
Status: current
Description: This Information Element carries n octets from the data link frame of a selected frame, starting sectionOffset octets into the frame. However, when the sectionOffset field corresponding to this Information Element does not exist, the octets MUST be from the start of the data link frame. The sectionExportedOctets expresses how much data was observed, while the remainder is padding. When the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or MAY have a variable length. When the sectionExportedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded. In this case, the size of the exported section may be constrained due to limitations in the IPFIX protocol. Further Information Elements, i.e., dataLinkFrameType and dataLinkFrameSize are needed to specify the data link type and the
size of the data link frame of this Information Element. A set of these Information Elements MAY be contained in a structured data type, as expressed in [RFC6313]. Or a set of these Information Elements MAY be contained in one Flow Record as shown in Appendix B of [ RFC-to-be ].
Range:
References: [ RFC-to-be ]

ElementID: mplsLabelStackSection
Name: 316
Data Type: octetArray
Data Type Semantics:
Status: current
Description: This Information Element carries a series of n octets from the MPLS label stack of a sampled packet, starting sectionOffset octets into the MPLS label stack. However, when the sectionOffset field corresponding to this Information Element does not exist, the octets MUST be from the head of the MPLS label stack. With sufficient length, this element also reports octets from the MPLS payload, subject to [RFC2804]. See the Security Considerations section in [RFC5477]. See [RFC3031] for the specification of MPLS packets. See [RFC3032] for the specification of the MPLS label stack. The sectionExportedOctets expresses how much data was observed, while the remainder is padding. When the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or MAY have a variable length. When the sectionExportedOctets field corresponding to this Information Element does not exist, this Information E
lement SHOULD have a variable length and MUST NOT be padded. In this case, the size of the exported section may be constrained due to limitations in the IPFIX protocol.
Range:
References: [ RFC-to-be ]

ElementID: 317
Name: mplsPayloadPacketSection
Data Type: octetArray
Data Type Semantics:
Status: current
Description: The mplsPayloadPacketSection carries a series of n octets from the MPLS payload of a sampled packet, starting sectionOffset octets into the MPLS payload, being data that follows immediately after the MPLS label stack. However, when the sectionOffset field corresponding to this Information Element does not exist, the octets MUST be from the start of the MPLS payload. See [RFC3031] for the specification of MPLS packets. See [RFC3032] for the specification of the MPLS label stack. The sectionExportedOctets expresses how much data was observed, while the remainder is padding. When the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or MAY have a variable length. When the sectionExportedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded. In this case, the size of the exported
  section may be constrained due to limitations in the IPFIX protocol.
Range:
References: [ RFC-to-be ]

Second, also in the IPFIX Information Elements registry in the IP Flow Information Export (IPFIX) Entities page at

http://www.iana.org/assignments/ipfix/

the following new entries will be registered:

ElementID: [ TBD-at-registration ]
Name: dataLinkFrameType
Data Type: unsigned16
Data Type Semantics: flags
Status: current
Description: This Information Element specifies the type of the selected data link frame. The following data link types are defined here.

- 0x01 IEEE802.3 ETHERNET [IEEE802.3]

- 0x02 IEEE802.11 MAC Frame format [IEEE802.11]

Further values may be assigned by IANA. Note that the assigned values are bits so that multiple observations can be OR'd together. The data link layer is defined in [ISO_IEC.7498-1_1994].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: sectionOffset
Data Type: unsigned16
Data Type Smantics: quantity
Status: current
Description: This Information Element specifies the offset of the packet section (e.g., dataLinkFrameSection, ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection and mplsPayloadPacketSection). If this Information Element is omitted, it defaults to zero (ie, no offset). If multiple sectionOffset IEs are specified within a single Template, then they apply to the packet section IEs in order. ie, the first sectionOffset applies to the first packet section, etc. Note that the "closest" sectionOffset and packet section IEs within a given Template are not necessarily related. If there are less sectionOffset IEs than packet section IEs, then subsequent packet section IEs have no offset. If there are more sectionOffset IEs than the number of packet section IEs, then the additional sectionOffset IEs are meaningless.
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: sectionExportedOctets
Data Type: unsigned16
Data Type Semantics: quantity
Status: current
Description: This Information Element specifies the observed length of the packet section (e.g., dataLinkFrameSection, ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection and mplsPayloadPacketSection) when padding is used. The packet section may be of a fixed size larger than the sectionExportedOctets. In this case, octets in the packet section beyond the sectionExportedOctets MUST follow the [RFC7011] rules for padding (ie, be composed of zero (0) valued octets).
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: dot1qServiceInstanceTag
Data Type: octetArray
Data Type Semantics: identifier
Status: current
Description: This Information Element, which is 16 octets long, represents the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame as described in [IEEE802.1Q]. It encodes the Backbone Service Instance Priority Code Point (I-PCP), Drop Eligible Indicator (I-DEI), Use Customer Addresses (UCA), Backbone Service Instance Identifier (I-SID), Encapsulated Customer Destination Address (C-DA), Encapsulated Customer Source Address (C-SA) and reserved fields. The structure and semantics within the Tag Control Information field are defined in [IEEE802.1Q].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: dot1qServiceInstanceId
Data Type: unsigned32
Data Type Semantics: identifier
Status: current
Description: The value of the 24-bit Backbone Service Instance Identifier (I-SID) portion of the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame as described in [IEEE802.1Q].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: dot1qServiceInstancePriority
Data Type: unsigned8
Data Type Semantics: identifier
Status: current
Description: The value of the 3-bit Backbone Service Instance Priority Code Point (I-PCP) portion of the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame as described in [IEEE802.1Q].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: dot1qCustomerSourceMacAddress
Data Type: macAddress
Data Type Semantics: identifier
Status: current
Description: The value of the Encapsulated Customer Source Address (C-SA) portion of the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame as described in [IEEE802.1Q].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: dot1qCustomerDestinationMacAddress
Data Type: macAddress
Data Type Semantics: identifier
Status: current
Description: The value of the Encapsulated Customer Destination Address (C-DA) portion of the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame as described in [IEEE802.1Q].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: l2OctetDeltaCount
Data Type: unsigned64
Data Type Semantics: deltaCounter
Status: current
Description: The number of layer 2 octets since the previous report (if any) in incoming packets for this Flow at the Observation Point. The number of octets includes layer 2 header(s) and layer 2 payload. This Information Element is the layer 2 version of octetDeltaCount (ElementId #1) in [RFC5477].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: postL2OctetDeltaCount
Data Type: unsigned64
Data Type Semantics: deltaCounter
Status: current
Description: The definition of this Information Element is identical to the definition of Information Element 'l2OctetDeltaCount', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. This Information Element is the layer 2 version of postOctetDeltaCount (ElementId #23) in [RFC5477].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: postMCastL2OctetDeltaCount
Data Type: unsigned64
Data Type Semantics: deltaCounter
Status: current
Description: The number of layer 2 octets since the previous report (if any) in outgoing multicast packets sent for packets of this Flow by a multicast daemon within the Observation Domain. This property cannot necessarily be observed at the Observation Point, but may be retrieved by other means. The number of octets includes layer 2 header(s) and layer 2 payload. This Information Element is the layer 2 version of postMCastOctetDeltaCount (ElementId #20) in [RFC5477].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: l2OctetTotalCount
Data Type: unsigned64
Data Type Semantics: totalCounter
Status: current
Description: The total number of layer 2 octets in incoming packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. The number of octets includes layer 2 header(s) and layer 2 payload. This Information Element is the layer 2 version of octetTotalCount (ElementId #85) in [RFC5477].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: postL2OctetTotalCount
Data Type: unsigned64
Data Type Semantics: totalCounter
Status: current
Description: The definition of this Information Element is identical to the definition of Information Element 'l2OctetTotalCount', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. This Information Element is the layer 2 version of postOctetTotalCount (ElementId #171) in [RFC5477].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: postMCastL2OctetTotalCount
Data Type: unsigned64
Data Type Semantics: totalCounter
Status: current
Description: The total number of layer 2 octets in outgoing multicast packets sent for packets of this Flow by a multicast daemon in the Observation Domain since the Metering Process (re-)initialization. This property cannot necessarily be observed at the Observation Point, but may be retrieved by other means. The number of octets includes layer 2 header(s) and layer 2 payload. This Information Element is the layer 2 version of postMCastOctetTotalCount (ElementId #175) in [RFC5477].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: minimumL2TotalLength
Data Type: unsigned64
Data Type Semantics:
Status: current
Description: Layer 2 length of the smallest packet observed for this Flow. The packet length includes the layer 2 header(s) length and the layer 2 payload length. This Information Element is the layer 2 version of minimumIpTotalLength (ElementId #25) in [RFC5477].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: maximumL2TotalLength
Data Type: unsigned64
Data Type Semantics:
Status: current
Description: Layer 2 length of the largest packet observed for this Flow. The packet length includes the layer 2 header(s) length and the layer 2 payload length. This Information Element is the layer 2 version of maximumIpTotalLength (ElementId #26) in [RFC5477].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: droppedL2OctetDeltaCount
Data Type: unsigned64
Data Type Semantics:
Status: current
Description: The number of layer 2 octets since the previous report (if any) in packets of this Flow dropped by packet treatment. The number of octets includes layer 2 header(s) and layer 2payload. This Information Element is the layer 2 version of droppedOctetDeltaCount (ElementId #132) in [RFC5477].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: droppedL2OctetTotalCount
Data Type: unsigned64
Data Type Semantics: totalCounter
Status: current
Description: The number of layer 2 octets since the previous report (if any) in packets of this Flow dropped by packet treatment. The number of octets includes layer 2 header(s) and layer 2 payload. This Information Element is the layer 2 version of droppedOctetTotalCount (ElementId #134) in [RFC5477].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: ignoredL2OctetTotalCount
Data Type: unsigned64
Data Type Semantics: totalCounter
Status: current
Description: The total number of octets in observed layer 2 packets (including the layer 2 header) that the Metering Process did not process since the (re-)initialization of the Metering Process. This Information Element is the layer 2 version of ignoredOctetTotalCount (ElementId #165) in [RFC5477].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: notSentL2OctetTotalCount
Data Type: unsigned64
Data Type Semantics: totalCounter
Status: current
Description: The total number of octets in observed layer 2 packets (including the layer 2 header) that the Metering Process did not process since the (re-)initialization of the Metering Process. This Information Element is the layer 2 version of notSentOctetTotalCount (ElementId #168) in [RFC5477].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: l2OctetDeltaSumOfSquares
Data Type: unsigned64
Data Type Semantics: deltaCounter
Status: current
Description: The sum of the squared numbers of layer 2 octets per incoming packet since the previous report (if any) for this Flow at the Observation Point. The number of octets includes layer 2 header(s) and layer 2 payload. This Information Element is the layer 2 version of octetDeltaSumOfSquares (ElementId #198) in [RFC5477].
Range:
References: [ RFC-to-be ]

ElementID: [ TBD-at-registration ]
Name: l2OctetTotalSumOfSquares
Data Type: unsigned64
Data Type Semantics: totalCounter
Status: current
Description: The total sum of the squared numbers of layer 2 octets in incoming packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. The number of octets includes layer 2 header(s) and layer 2 payload. This Information Element is the layer 2 version of octetTotalSumOfSquares (ElementId #199) in [RFC5477].
Range:
References: [ RFC-to-be ]

IANA understands that these two actions are the only one required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Information Elements for Data Link Layer Traffic Measurement) to Proposed Standard


The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Information Elements for Data Link Layer Traffic Measurement'
  as Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-10-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes Information Elements related to the data link
  layer.  They are used by the IP Flow Information Export (IPFIX)
  protocol for encoding measured data link layer traffic information.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring/ballot/


No IPR declarations have been submitted directly on this I-D.