Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX)
draft-yourtchenko-cisco-ies-11

[Ballot discuss]
One question in section 7:

"However, the export of the sections of the packet payload may
  unintentionally change the security assumptions of other protocols."

What does this mean, exactly? Is this document saying anything different from what is said in RFC 7012, or the security assumptions described in RFC 7011?

IESG/Authors/WG Chairs:

IANA has reviewed draft-yourtchenko-cisco-ies-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

NOTE: The designated expert team for this registry is still reviewing these registrations.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the IPFIX Information Elements registry at

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

provided the designated experts approve, 18 information elements will be registered as follows:

ElementID: 34
Name:  samplingInterval
Data Type: unsigned32
Data Type Semantics: quantity
Status: deprecated
Description:      Deprecated in favor of 305 samplingPacketInterval.  When using sampled NetFlow, the rate at which packets are sampled - e.g. a value of 100 indicates that one of every 100 packets is sampled.
Units: packets
Range:
References:
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 35
Name:  samplingAlgorithm
Data Type: unsigned8
Data Type Semantics: identifier
Status: deprecated
Description: Deprecated in favor of 304 selectorAlgorithm.  The type of algorithm used for sampled NetFlow:
        1 - Deterministic Sampling;
        2 - Random Sampling.
The values are not compatible with the selectorAlgorithm IE, where "Deterministic" has been replaced by "Systematic count-based" (1) or "Systematic time-based" (2), and "Random" is (3).  Conversion is required, see PSAMP parameters [PSAMP-IANA]. 
Units:
Range:
References:
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 38
Name: engineType
Data Type: unsigned8
Data Type Semantics: identifier
Status: deprecated
Description: Type of flow switching engine in a router/switch:

        RP = 0,
        VIP/Line card = 1,
        PFC/DFC = 2.

Reserved for internal use on the collector.   
Units:
Range:
References:
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 39
Name:  engineID
Data Type: unsigned8
Data Type Semantics: identifier
Status: deprecated
Description:  VIP or line card slot number of the flow switching engine in a router/switch.  Reserved for internal use on the collector.   
Units:
Range:
References:
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 43
Name:  ipv4RouterSc
Data Type: ipv4Address
Data Type Semantics: identifier
Status: deprecated
Description: This is a platform-specific field for Catalyst 5000/Catalyst 6000 family.  It is used to store the address of a router that is being shortcut when performing MultiLayer Switching.
Units:
Range:
References: [ http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a00800ab513.shtml ] describes the MultiLayer Switching.
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 48
Name:  samplerId
Data Type: unsigned8
Data Type Semantics: identifier
Status: deprecated
Description:  Deprecated in favor of 302 selectorId.  The unique identifier associated with samplerName.   
Units:
Range:
References:
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 49
Name:  samplerMode
Data Type: unsigned8
Data Type Semantics: identifier
Status: deprecated
Description: Deprecated in favor of 304 selectorAlgorithm.  The values are not compatible: selectorAlgorithm=3 is random sampling.  The type of algorithm used for sampling data: 1 - deterministic, 2 - random sampling.  Use with samplerRandomInterval.   
Units:
Range:
References:
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 50
Name:  samplerRandomInterval
Data Type: unsigned32
Data Type Semantics: quantity
Status: deprecated
Description:  Deprecated in favour of 305 samplingPacketInterval.  Packet interval at which to sample - in case of random sampling.  Used in connection with samplerMode 0x02 (random sampling) value.
Units:
Range:
References:
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 51
Name:  classId
Data Type: unsigned8
Data Type Semantics: identifier
Status: deprecated
Description: Deprecated in favour of 302 selectorId.  Characterizes the traffic class, i.e. QoS treatment. 
Units:
Range:
References:
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 84
Name:  samplerName
Data Type: string
Data Type Semantics:
Status: deprecated
Description:  Deprecated in favor of 335 selectorName.  Name of the flow sampler.   
Units:
Range:
References:
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 87
Name:  flagsAndSamplerId
Data Type: unsigned32
Data Type Semantics: identifier
Status: deprecated
Description:  Flow flags and the value of the sampler ID (samplerId) combined in one bitmapped field.  Reserved for internal use on the collector. 
Units:
Range:
References:
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 89
Name:  forwardingStatus
Data Type: unsigned32
Data Type Semantics: identifier
Status: current
Description:  This Information Element describes the forwarding status of the flow and any attached reasons.  The Reduced Size Encoding rules as per [RFC7011] apply.

The basic encoding is 8 bits. The future extensions could add one or three bytes. The layout of the basic encoding is as follows:

        MSB -  0  1  2  3  4  5  6  7  - LSB
              +---+---+---+---+---+---+---+---+
              | Status|  Reason code or flags |
              +---+---+---+---+---+---+---+---+
      Status:

      00b = Unknown
      01b = Forwarded
      10b = Dropped
      11b = Consumed

      Reason Code (status = 01b, Forwarded)

      01 000000b = 64 = Unknown
      01 000001b = 65 = Fragmented
      01 000010b = 66 = Not Fragmented

      Reason Code (status = 10b, Dropped)

      10 000000b = 128 = Unknown
      10 000001b = 129 = ACL deny
      10 000010b = 130 = ACL drop
      10 000011b = 131 = Unroutable
      10 000100b = 132 = Adjacency
      10 000101b = 133 = Fragmentation and DF set
      10 000110b = 134 = Bad header checksum
      10 000111b = 135 = Bad total Length
      10 001000b = 136 = Bad header length
      10 001001b = 137 = bad TTL
      10 001010b = 138 = Policer
      10 001011b = 139 = WRED
      10 001100b = 140 = RPF
      10 001101b = 141 = For us
      10 001110b = 142 = Bad output interface
      10 001111b = 143 = Hardware

      Reason Code (status = 11b, Consumed)

      11 000000b = 192 = Unknown
      11 000001b = 193 = Punt Adjacency
      11 000010b = 194 = Incomplete Adjacency
      11 000011b = 195 = For us

      Examples:

        value : 0x40 = 64
        binary: 01000000
        decode: 01        -> Forward
                  000000  -> No further information

        value : 0x89 = 137
        binary: 10001001
        decode: 10        -> Drop
                  001001  -> Fragmentation and DF set   
Units:
Range:
References: See http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a00800ab513.shtml - NetFlow Version 9 Record Format.
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 92
Name:  srcTrafficIndex
Data Type: unsigned32
Data Type Semantics: identifier
Status: current
Description: BGP Policy Accounting Source Traffic Index 
Units:
Range:
References: BGP policy accounting as described in [http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094e88.shtml]
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 93
Name:  dstTrafficIndex
Data Type: unsigned32
Data Type Semantics: identifier
Status: current
Description: BGP Policy Accounting Destination Traffic Index 
Units:
Range:
References: BGP policy accounting as described in [http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094e88.shtml]
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 100
Name:  className
Data Type: string
Data Type Semantics:
Status: deprecated
Description:  Deprecated in favor of 335 selectorName.  Traffic Class Name, associated with the classId Information Element.   
Units:
Range:
References:
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 102
Name: layer2packetSectionOffset
Data Type: unsigned16
Data Type Semantics: quantity
Status: deprecated
Description:  Deprecated in favor of sectionOffset (409).  Layer 2 packet section offset.  Potentially a generic packet section offset. 
Units:
Range:
References:
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 103
Name: layer2packetSectionSize
Data Type: unsigned16
Data Type Semantics: quantity
Status: deprecated
Description: Deprecated in favor of dataLinkFrameSize(312).  Layer 2 packet section size.  Potentially a generic packet section size. 
Units:
Range:
References:
Requestor: [ RFC-to-be ]
Revision: 0

ElementID: 104
Name: layer2packetSectionData
Data Type: octetArray
Data Type Semantics:
Status: deprecated
Description: Deprecated in favor of dataLinkFrameSection (315).  Layer 2 packet section data.   
Units:
Range:
References:
Requestor: [ RFC-to-be ]
Revision: 0

IANA understands that this is the only action 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:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-yourtchenko-cisco-ies-09.txt> (Cisco Specific Information Elements reused in IPFIX) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Cisco Specific Information Elements reused in IPFIX'
  <draft-yourtchenko-cisco-ies-09.txt> as Informational RFC

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 2014-02-18. 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 some additional Information Elements of Cisco
  Systems, Inc. that are not listed in RFC3954.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-yourtchenko-cisco-ies/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-yourtchenko-cisco-ies/ballot/


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

Write-up for:
  draft-yourtchenko-cisco-ies-08
  Cisco Specific Information Elements reused in IPFIX

=== 1. Summary ===

Document shepherd: Nevil Brownlee
Responsible Area Director: Joel Jaeggli

The document is intended to be Informational, AD-sponsored by Joel.
It describes additional Information Elements of Cisco
Systems, Inc. that are not listed in RFC3954.

Section 4 of [RFC7012] defines the IPFIX Information Elements in
the range of 1-127 to be compatible with the NetFlow version 9
fields, as specified in the "Cisco Systems NetFlow Services Export
Version 9" [RFC3954].  Since [RFC3954] was specified in 2004, it does
not contain all NetFlow version 9 specific fields in the range 1-127.
This document is intended to complete the IPFIX Information Elements
IANA registry, filling the gaps in the range 1-127.

=== 2. Review and Consensus ===

This draft's -00 version was published in July 2011. All three
authors are from Cisco Systems.  Since then the draft was presented
a few times during IPFIX meetings. However, not much feedback
was received as this is mainly a FYI-type of document. Nonetheless,
there is clear value in the document, as the range 1-127 was
in fact a gimmick to take into account the NetFlow evolution while
the IPFIX standard was being specified.

=== 3. Intellectual Property ===

No IPR disclosures have been made directly on this draft, IPR
on it has not been discussed in the WG.

=== 4. Other Points ===

This document has no downward references.

Its IANA Considerations clearly state what IANA is being asked
to do, i.e. add some new IPFIX Information Elements to the
IPFIX Information Element Registry.  Note that one author
is one of the IE-Doctors.

The ID-nits checker has no complaints.

Overall, I believe that this draft is ready for publication as
an RFC.

Write-up for:
  draft-yourtchenko-cisco-ies-08
  Cisco Specific Information Elements reused in IPFIX

=== 1. Summary ===

Document shepherd: Nevil Brownlee
Responsible Area Director: Joel Jaeggli

The document is intended to be Informational, AD-sponsored by Joel.
It describes additional Information Elements of Cisco
Systems, Inc. that are not listed in RFC3954.

Section 4 of [RFC7012] defines the IPFIX Information Elements in
the range of 1-127 to be compatible with the NetFlow version 9
fields, as specified in the "Cisco Systems NetFlow Services Export
Version 9" [RFC3954].  Since [RFC3954] was specified in 2004, it does
not contain all NetFlow version 9 specific fields in the range 1-127.
This document is intended to complete the IPFIX Information Elements
IANA registry, filling the gaps in the range 1-127.

=== 2. Review and Consensus ===

This draft's -00 version was published in July 2011. All three
authors are from Cisco Systems.  Since then the draft was presented
a few times during IPFIX meetings. However, not much feedback
was received as this is mainly a FYI-type of document. Nonetheless,
there is clear value in the document, as the range 1-127 was
in fact a gimmick to take into account the NetFlow evolution while
the IPFIX standard was being specified.

=== 3. Intellectual Property ===

No IPR disclosures have been made directly on this draft, IPR
on it has not been discussed in the WG.

=== 4. Other Points ===

This document has no downward references.

Its IANA Considerations clearly state what IANA is being asked
to do, i.e. add some new IPFIX Information Elements to the
IPFIX Information Element Registry.  Note that one author
is one of the IE-Doctors.

The ID-nits checker has no complaints.

Overall, I believe that this draft is ready for publication as
an RFC.

Write-up for:
  draft-yourtchenko-cisco-ies-08
  Cisco Specific Information Elements reused in IPFIX

=== 1. Summary ===

Document shepherd: Nevil Brownlee
Responsible Area Director: Joel Jaeggli

The document is intended to be Informational, AD-sponsored by Joel.
It describes additional Information Elements of Cisco
Systems, Inc. that are not listed in RFC3954.

Section 4 of [RFC7012] defines the IPFIX Information Elements in
the range of 1-127 to be compatible with the NetFlow version 9
fields, as specified in the "Cisco Systems NetFlow Services Export
Version 9" [RFC3954].  Since [RFC3954] was specified in 2004, it does
not contain all NetFlow version 9 specific fields in the range 1-127.
This document is intended to complete the IPFIX Information Elements
IANA registry, filling the gaps in the range 1-127.

=== 2. Review and Consensus ===

This draft's -00 version was published in July 2011. All three
authors are from Cisco Systems.  Since then the draft was presented
a few times during IPFIX meetings. However, not much feedback
was received as this is mainly a FYI-type of document. Nonetheless,
there is clear value in the document, as the range 1-127 was
in fact a gimmick to take into account the NetFlow evolution while
the IPFIX standard was being specified.

=== 3. Intellectual Property ===

No IPR disclosures have been made directly on this draft, IPR
on it has not been discussed in the WG.

=== 4. Other Points ===

This document has no downward references.

Its IANA Considerations clearly state what IANA is being asked
to do, i.e. add some new IPFIX Information Elements to the
IPFIX Information Element Registry.  Note that one author
is one of the IE-Doctors.

The ID-nits checker has no complaints.

Overall, I believe that this draft is ready for publication as
an RFC.