Subject: [ipfix-info] simple editorial changes for the information model draft

From: Benoit Claise <[email-masked]>
Date: Tue, 07 Jun 2005 23:45:44 +0200

Juergen,

I reviewed the information model draft one last time.

For everybody interest, we discussed with Juergen a list of new I.E. to be added.
However, as we wanted to make the date of June 1st for the last-call, and as these new I.E. can be considered as editorial changes, these new I.E.s were not inserted in the current draft version.
These I.E. will be the subject of a separate email.

Here is a list of simple editorial changes.

 - 
http://ietf.levkowetz.com/drafts/ipfix/info/draft-ietf-ipfix-info-07.nits.txt

- Section 4, Information Element Identifiers

   "Enterprise-specific identifiers can be chosen by an enterprise
   arbitrarily within the range of 1-32767.  The same identifier may be
   assigned by other enterprises for different purposes."

	-> 
   "Enterprise-specific Information Elements identifiers can be chosen by an enterprise
   arbitrarily within the range of 1-32767.  The same identifier may be
   assigned by other enterprises for different purposes."

- Section 4, Information Element Identifiers

   "The following list gives an overview of the Information Element
   identifiers that are specified in section 5 and are not compatible
   with field types used by NetFlow version 9 [RFC3954]"

	-> 
   "The following list gives an overview of the Information Element
   identifiers that are specified in section 5 and are compatible
   with Information Elements used by NetFlow version 9 [RFC3954]"

- Section 5.  Information Elements

   "The Information Elements that are derived from fields of packets or
   from packet treatment, such as the Information Elements in groups
   3.-6., can serve as Flow Keys used for mapping packets to flows.  But
   they also may contain values that are not constant for a single flow.
   For example a flow using a certain source IPv4 address as flow key
   has sourceIPv4Address as constant property but may have
   destinationIPv4Address as a property that changes from packet to
   packet."

I don't understand the sentence starting with "But".
Either this is a flow key, and then this I.E. is constant in a flow.
Or it's not a flow key and it's not worth mentioning!
I mean... by definition a flow is defined by his flow keys. So the following sentence is wrong
"But they (I understand by "they", the I.E.s that serve as Flow Keys" also may contain values that are not constant for a single flow."

- Section 5.  Information Elements

   For such Information Elements that are derived from fields of packets
   or from packet treatment, the IPFIX information model makes the
   general assumption that their value is determined by the first packet
   observed for the corresponding Flow, unless the description of the
   Information Element explicitly specifies a different semantics.  

	semantics -> semantic

- Section 5.2.5  exportedFlowTotalCount

   Description:
      The total number of Flows Records reported that the Exporting
      Process successfully sent as Data Records since the Exporting
      Process (re-)initialization to the Collecting Process receiving a
      report that contains this Information Element. 

   What does "reported" mean? Can't we simply delete it?

- Section 5.2.6  observedFlowTotalCount

   Description:
      The total number of Flows observed in the Observation Domain since
      the Metering Process (re-)initialization for this Observation
      Point.
   ElementId: 3

  We should be in line with the RFC 3954 that explains something different: Number of Flows that were aggregated;

- Section 5.7  Min/Max Flow Properties

   Information Elements in this section are results of minimum or
   maximum operations over all packets of a flow.

TCP flags and ipv6OptionHeaders don't fall into this description.
New proposal: 

"Information Elements in this section are results of minimum or maximum 
operations over all packets of a flow.Information Elements in this 
section are the results of minimum, a maximum, or a logical operations 
over all packets of a flow."

- 5.7.5  ipv6OptionHeaders

 New proposal:

Description:
     IPv6 extension headers observed in packets of this flow.  The
     information is encoded in a set of bit fields.  For each IPv6
     option header there is a bit in this set.  The bit is set to 1 if
     any observed packet of this flow contains the corresponding IPv6
     extension header.  Otherwise, if no observed packet of this flow
     contained the resepective IPv6 extension header, the value of the
     corresponding bit is 0.

              0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          | Res | FRA1| ROU | FRA0| UNK | Res | HOP | DST |  ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

              8     9    10    11    12    13    14    15
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... | PAY | AUT | ENC |         Reserved            | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             16    17    18    19    20    21    22    23
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |                  Reserved                     | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             24    25    26    27    28    29    30    31
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |                  Reserved                     |
          +-----+-----+-----+-----+-----+-----+-----+-----+

      Bit     IPv6 Option   Description

       0, Res               Reserved
       1, FRA1     44       Fragmentation header - not first fragment
       2, ROU      43       Routing header
       3, FRA0     44       Fragment header - first fragment
       4, UNK               Unknown Layer 4 header
                           (compressed, encrypted, not supported)
       5, Res               Reserved
       6, HOP       0       Hop-by-hop option header
       7, DST      60       Destination option header
       8, PAY     108       Payload compression header
       9, AUT      51       Authentication Header
      10, ENC     50        Encrypted security payload
      11 to 31              Reserved

- Capitalization
    A lot of instances where "IPFIX message" is not capitalized.
    A couple of instances where "IPFIX device" is not capitalized
    "flow" sometimes is in lower case, should be "Flow"

- Section 5.10.3 flowEndReason

   Description:
      The reason for flow termination.  The range of values includes
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 136
   Status: current

The description is incomplete. The person who requested it should 
complete the description

- Section 6.  Extending the Information Model

   Extension is done by defining new Information Elements.  Each new
   information item MUST be assigned a unique Information Element
   identifier as part of its definition.  

    ->

   Extension is done by defining new Information Elements.  Each new
   Information Element MUST be assigned a unique Information Element
   identifier as part of its definition.  

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 17 Jun 2005 06:41:08 +0200

Dear all,

Here is the list of additional Information Elements that Benoit announced.
I apologize for posting them late (after the announced end of WG last call).

--On 6/7/2005 11:45 PM +0200 Benoit Claise wrote:
> For everybody interest, we discussed with Juergen a list of new I.E.
> to be added.  However, as we wanted to make the date of June 1st for
> the last-call, and as these new I.E. can be considered as editorial
> changes, these new I.E.s were not inserted in the current draft version.

The actual list of suggested new elements was much longer than posted
below.  We removed all suggestions where we had any doubt about usefulness
or clarity and precision of the specification.

Below please find first the list of suggested elements with suggested
section numbers in the info model I-D,  suggested Information Element
identifier, and suggested name.  The list is followed by a full description
of all suggested elements.

Please have a look at them and state your opinion on whether or not you
think we should include them in the IPFIX info model.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

section   ID  name

5.3.14    192 ipTimeToLive
5.3.15    193 nextHeaderIPv6
5.3.24    189 ipHeaderLength
5.3.25    190 packetLengthIPv4
5.3.26    191 payloadLengthIPv6
5.4.3     180 udpSourcePort
5.4.4     181 udpDestinationPort
5.4.5     182 tcpSourcePort
5.4.6     183 tcpDestinationPort
5.4.7     184 tcpSequenceNumber
5.4.8     185 tcpAcknowledgementNumber
5.4.9     186 tcpWindowSize
5.4.10    187 tcpUrgentPointer
5.4.11    188 tcpHeaderLength
5.4.13    176 icmpTypeIPv4
5.4.14    177 icmpCodeIPv4
5.4.16    178 icmpTypeIPv6
5.4.17    179 icmpCodeIPv6
5.5.9     196 mplsTopLabelTtl
5.5.10    197 mplsLabelStackSize
5.9.3     194 octetDeltaSumOfSquares
5.9.6     195 octetTotalSumOfSquares
5.9.17    174 postMCastPacketTotalCount
5.9.18    175 postMCastOctetTotalCount

5.3.14  ipTimeToLive

   Description:
      For IPv4, the value of the Information Element matches the value
      of the Time to Live field in the IPv4 packet header.  For IPv6,
      the value of the Information Element matches the value of the Hop
      Limit field in the IPv6 packet header.
   Abstract Data Type: octet
   ElementId: 192
   Status: current
   Units: hops
   Reference: See RFC 791 for the definition of the IPv4 Time to Live
      field.  See RFC 2460 for the definition of the IPv6 Hop Limit
      field.

5.3.15  nextHeaderIPv6

   Description:
      The value of the Next Header field of the IPv6 header.
   Abstract Data Type: octet
   ElementId: 193
   Status: current
   Reference: See RFC 2460 for the definition of the IPv6 Next Header
      field.

5.3.24  ipHeaderLength

   Description:
      The length of the IP header.  For IPv6, the value of this
      Information Element is 40.
   Abstract Data Type: octet
   ElementId: 189
   Status: current
   Reference:
      See RFC 791 for the specification of the IPv4 header.  See RFC
      2460 for the specification of the IPv6 header.

5.3.25  packetLengthIPv4

   Description:
      The total length of the IPv4 packet.
   Abstract Data Type: unsigned16
   ElementId: 190
   Status: current
   Units: octets
   Reference:
      See RFC 791 for the specification of the IPv4 total length.

5.3.26  payloadLengthIPv6

   Description:
      The length of the IPv6 payload, i.e., the rest of the packet
      following the IPv6 header, in octets.  Note that any extension
      headers  present are considered part of the payload, i.e.,
      included in the length count.  For payload lengths up to 65535,
      the value of this Information Element is given by the payload
      length field of the IPv6 header.  For payload lengths greater than
      65535, the value of this Information Element is given by the
      content of the IPv4 jumbo payload option.
   Abstract Data Type: unsigned32
   ElementId: 191
   Status: current
   Reference:
      See RFC 2460 for the specification of the IPv6 payload length.
      See RFC 2675 for the specification of the IPv6 jumbo payload
      length.

5.4.3  udpSourcePort

   Description: The source port identifier in the UDP header.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 180
   Status: current
   Reference: See RFC 768 for the definition of the UDP source port
      field.  Additional information on defined UDP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.4.4  udpDestinationPort

   Description: The destination port identifier in the UDP header.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 181
   Status: current
   Reference: See RFC 768 for the definition of the UDP source port
      field.  Additional information on defined UDP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.4.5  tcpSourcePort

   Description: The source port identifier in the TCP header.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 182
   Status: current
   Reference: See RFC 793 for the definition of the TCP source port
      field.  Additional information on defined TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.4.6  tcpDestinationPort

   Description: The destination port identifier in the TCP header.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 183
   Status: current
   Reference: See RFC 793 for the definition of the TCP source port
      field.  Additional information on defined TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.4.7  tcpSequenceNumber

   Description: The sequence number in the TCP header.
   Abstract Data Type: unsigned32
   ElementId: 184
   Status: current
   Reference: See RFC 793 for the definition of the TCP sequence number.

5.4.8  tcpAcknowledgementNumber

   Description: The acknowledgement number in the TCP header.
   Abstract Data Type: unsigned32
   ElementId: 185
   Status: current
   Reference: See RFC 793 for the definition of the TCP acknowledgement
      number.

5.4.9  tcpWindowSize

   Description: The window field in the TCP header.
   Abstract Data Type: unsigned16
   ElementId: 186
   Status: current
   Reference: See RFC 793 for the definition of the TCP window field.

5.4.10  tcpUrgentPointer

   Description: The urgent pointer in the TCP header.
   Abstract Data Type: unsigned16
   ElementId: 187
   Status: current
   Reference: See RFC 793 for the definition of the TCP urgent pointer.

5.4.11  tcpHeaderLength

   Description: The length of the TCP header.
   Abstract Data Type: unsigned16
   ElementId: 188
   Status: current
   Units: octets
   Reference: See RFC 793 for the definition of the TCP header.

5.4.13  icmpTypeIPv4

   Description:
      Type of the IPv4 ICMP message.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 176
   Status: current
   Reference: See RFC 792 for a definition of the IPv4 ICMP type field.

5.4.14  icmpCodeIPv4

   Description:
      Code of the IPv4 ICMP message.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 177
   Status: current
   Reference: See RFC 792 for a definition of the IPv4 ICMP code field.

5.4.16  icmpTypeIPv6

   Description:
      Type of the IPv6 ICMP message.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 178
   Status: current
   Reference: See RFC 2463 for a definition of the IPv6 ICMP type field.

5.4.17  icmpCodeIPv6

   Description:
      Code of the IPv6 ICMP message.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 179
   Status: current
   Reference: See RFC 2463 for a definition of the IPv6 ICMP code field.

5.5.9  mplsTopLabelTtl

   Description: The TTL field from the top MPLS label stack entry, i.e.
      the last label that was pushed.
   Abstract Data Type: unsigned32
   ElementId: 196
   Status: current
   Reference: See RFC 3032 for the specification of the TTL field.

5.5.10  mplsLabelStackSize

   Description: The size of the MPLS label stack.
   Abstract Data Type: unsigned32
   ElementId: 197
   Status: current
   Units: octets
   Reference: See RFC 3032 for the specification of the MPLS label
      stack.

5.9.3  octetDeltaSumOfSquares

   Description:
      The sum of the squared numbers of octets per incoming packet since
      the previous report (if any) for this Flow at the Observation
      Point.  The number of octets include IP header(s) and IP payload.
   Abstract Data Type: unsigned64
   ElementId: 194
   Status: current

5.9.6  octetTotalSumOfSquares

   Description:
      The total sum of the squared numbers of 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 include IP header(s) and IP payload.
   Abstract Data Type: unsigned64
   ElementId: 195
   Status: current
   Units: octets

5.9.17  postMCastPacketTotalCount

   Description:
      The total number of outgoing multicast packets created for packets
      of this Flow by an adjacent multicast daemon since the Metering
      Process (re-)initialization.  Note that typically not all of the
      created packets can be observed at the Observation Point of this
      Flow.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 174
   Status: current
   Units: packets

5.9.18  postMCastOctetTotalCount

   Description:
      The total number of octets in outgoing multicast packets created
      for packets of this Flow by an adjacent multicast daemon since the
      Metering Process (re-)initialization.  Note that typically not all
      of the created packets can be observed at the Observation Point of
      this Flow.  The number of octets include IP header(s) and IP
      payload.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 175
   Units: octets

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Benoit Claise <[email-masked]>
Date: Mon, 20 Jun 2005 02:20:01 +0200

Hi Juergen,

Thanks for posting the list of I.E.s

You forgot some I.E.s that we discussed and agreed upon, as far as I 
remember.

1. mplsTopLabelEXP
   Description: the top MPLS label experimental bits.
   Abstract Data Type: octet
   Data Type Semantics: flags
   ElementId: x
   Status: current
   Reference 2.1 in RFC3032

2.  IPPayloadLength
    Description: Length of the IP payload in octets.
    Abstract Data Type: unsigned16
    Data Type Semantics: quantity
    ElementId: x
    Status: current

3. mplsHeaderLength
    Description: The sum of the MPLS label stack entries
    Abstract Data Type: octet
    Data Type Semantics: quanity
    ElementId: x
    Status: current

4. mplsPayloadLength: 
    Description: the payload after last MPLS label stack entry.
    Abstract Data Type: unsigned16
    Data Type Semantics: quantity
    ElementId: x
    Status: current

5.  IPTos
    Description: IP Type Of Service.
    Abstract Data Type: octet
    Data Type Semantics: identifier
    ElementId:  x
    Status: current

    Note: this is the full 8-bit octet
    Note:

6. IPDSCP
    Description: IP DSCP.
    ElementId: x
    Status: current
   
    Note: this is 6 bits of DSCP information

7. IPPrecedence
    Description: IP precedence.
    Abstract Data Type: octet
    Data Type Semantics: identifier
    ElementId: x
    Status: current
    Reference: RFC 791
    Note: this is the 3 bits of precedence information

8. IPv4HeaderLength
    Description: IPv4 header length .
    Abstract Data Type: unsigned16
    Data Type Semantics: quantity
    ElementId: x
    Status: current

9. IPv4Flags
    Description: IPv4 fragmentation flags.
    Abstract Data Type: 8bits
    Data Type Semantics: flags
    ElementId: x
    Status: current

10. IPv4Options
    Description: Bitmap representing which IPv4 options have been seen.
    Abstract Data Type: 32bits
    Data Type Semantics: flags
    ElementId: x
    Status: current
    Reference: "flags" from the IP header, RFC791

11. TCPOptions
    Description: TCP options field
    Abstract Data Type: 32bits
    Data Type Semantics: flags
    ElementId: x
    Status: current
    Reference: RFC 793

Here is one typo:
5.3.26  payloadLengthIPv6

  Description:

"IPv6" ----------^^^^

Finally, one comment regarding the two postMCastPacketTotalCount  and 
postMCastOctetTotalCount  I.E.
- is it important to specify "created for packets of this Flow by an 
adjacent multicast daemon"
- regarding to "Note that typically not all of the created packets can 
be observed at the Observation Point of this Flow.", I'm not sure it 
makes sense.
   What does "created" mean?
   If you want to say that all IPFIX device wide multicast packets can't 
be observed, I don't think this is relevant as the observation point is 
the interface.
   This is even confusing.

Regards, Benoit.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 20 Jun 2005 08:54:20 +0100

>    Data Type Semantics: quanity

Do you mean mplsStackDepth, or do you mean
mplsStackDepth * sizeof(labelStackEntry)?

If you mean mplsStackDepth, then we should change the name.

In looking at RFC3031, I notice that we have a problem
with the mplsLabelStackEntryx set of IEs. We say:

5.5.9  mplsLabelStackEntry1

    Description:
       The label, exp and s fields from the outermost MPLS label stack
       entry, i.e.  the last label that was pushed.

but RFC3031 says

3.9. The Label Stack

    <snip>

    If a packet's label stack is of depth m, we refer to the label at the
    bottom of the stack as the level 1 label, to the label above it (if
    such exists) as the level 2 label, and to the label at the top of the
    stack as the level m label.

Now I think that what we have defined is consistent with the Netflow
spec, but is unfortunately this is inconsistant with the notation
used in the MPLS architecture. Maybe all that is needed is a note
in the draft, but I think that we need to do something.

- Stewart

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 20 Jun 2005 15:14:08 +0200

Stewart,

> If you mean mplsStackDepth, then we should change the name.

It is already contained in the list I posted.
I renamed it to mplsLabelStackSize and specified 'octets' as unit.

> in the draft, but I think that we need to do something.

What about renaming mplsLabelStackEntry1 to mplsTopLabelEntry?
The others (mplsLabelStackEntry2 - mplsLabelStackEntry10) are defined
recursively based on mplsLabelStackEntry1.

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 20 Jun 2005 16:12:15 +0200

Benoit,

This is just a reply to you.  The mailing list is not yet included.

I am sorry for not posting the full list.  Accidentally, I omitted
ipTypeOfService, ipDscp, and ipPrecedence.  Wit a bit more elaborated descriptions,
their proposed specification is

5.3.16  ipClassOfService

   Description:
      For IPv4 packets, this is the value of the TOS field in the IPv4
      packet header, for IPv6 packets, this is the value of the Traffic
      Class field in the IPv6 packet header.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 194
   Status: current
   Reference: See RFC 791 for the definition of the IPv4 TOS field.  See
      RFC 2460 for the definition of the IPv6 Traffic Class field.

5.3.17  ipDiffServeCodePoint

   Description:
      The value of a Differentiated Services Code Point (DSCP).  DSCP
      values are encoded in the first 6 bits of the IPv4 TOS field or
      the IPv6 Traffic class field, respectively.
      For a particular Flow or packet, this Information Element may have
      the same value as Information Element ipClassOfService except that
      the bits that are not used by the Differentiated Services Field
      for specifying a DiffServ Code Point (DSCP) are to be ignored.
      Note that ignoring these bits may be relevant when the DSCP serves
      as Flow Key.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 195
   Status: current
   Reference: See RFC 791 for the definition of the IPv4 TOS field.  See
      RFC 2460 for the definition of the IPv6 Traffic Class field.  See
      RFC 2474 for the definition of the Differentiated Services Field.

5.3.18  ipPrecedence

   Description:
      The value of the IP Precedence.  IP Precedence values are encoded
      in the first 3 bits of the IPv4 TOS field or the IPv6 Traffic
      class field, respectively.
      For a particular Flow or packet, this Information Element may have
      the same value as Information Element ipClassOfService except that
      the last 5 bits are to be ignored.  Note that ignoring these bits
      may be relevant when the IP Precedence serves as Flow Key.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 196
   Status: current
   Reference: See RFC 791 for the definition of the IPv4 TOS field and
      the IP Precedence.  See RFC 2460 for the definition of the IPv6
      Traffic Class field.

5.3.27  fragmentFlagsIPv4

   Description:
      The value of the fragmentation bits in the IPv4 packet header.

         Bit 0:    reserved, must be zero.
         Bit 1:    (DF) 0 = May Fragment,  1 = Don't Fragment.
         Bit 2:    (MF) 0 = Last Fragment, 1 = More Fragments.
         Bits 3-7: (DC) Don't Care, value is irrelevant.

             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           |   | D | M | D | D | D | D | D |
           | 0 | F | F | C | C | C | C | C |
           +---+---+---+---+---+---+---+---+

   Abstract Data Type: octet
   Data Type Semantics: flags
   ElementId: 197
   Status: current
   Reference:
      See RFC 791 for the specification of the IPv4 fragment flags.

For the remaining Element you list I ran into open issues when specifying
them, particularly when reading the references to be included.
Please find comments inline below.

--On 6/20/2005 2:20 AM +0200 Benoit Claise wrote:

> You forgot some I.E.s that we discussed and agreed upon, as far as I remember.
>
> 1. mplsTopLabelEXP

1. These flags are already included in object mplsLabelStackEntry1.
2. I could not find references to any use of these experimental bits.
   RFC 3032 just says they are reserved.  Do we have an application
   scenario where these are used?

>     Data Type Semantics: quantity

The definitions of payload are different for IPv4 and IPv6.

For IPv4 there is no header field indicating the payload length,
we just have the 'total Length' header field.  The IPv4 actual payload
length is the difference between the 'Total Length' and the actual
header length.  The IPv4 header length is variable, because IPv4 optinons
are included in the header.

For IPv6 there is a 'Payload Length' field in the header :-),
but the actual payload length may differ from the value of this field :-(
For Jumbograms the value of the 'Payload Length' header field is zero
and the actual value is specified in an extensions header.

IPv4: actual payload length = packet length - base header length - total options length
IPv6: actual payload length = packet length - base header length

>     Data Type Semantics: quanity

This is included.  RFCs 3031/3032 rather call it MPLS label stack
than MPLS header.  That's why I renamed it to mplsLabelStackSize.

> 4. mplsPayloadLength:     Description: the payload after last MPLS label stack entry.

This is the IP packet length.
It should be called accordingly.

>     Note: this is the full 8-bit octet

I really missed this one.  Please see above.

>        Note: this is 6 bits of DSCP information

See above.

>     Note: this is the 3 bits of precedence information

See above.

>     Data Type Semantics: quantity

We have the IP header length.

>     Data Type Semantics: flags

I really missed this one.  Please see above.

>     Reference: "flags" from the IP header, RFC791

RFC 791 specifies 8 different options:
  1. End of Option list
  2. No Operation
  2. Security
  4. Loose Source Routing
  5. Strict Source Routing
  6. Record Route
  7. Stream ID
  8. Internet Timestamp

Options 1 and 2 do not contain real information, they
just serve syntactical and alignment purposes.
Shall we include them also or limit the option list to the remaining
six options.

Are there more options defined anywhere outside of RFC 791?
Do we really need and unsigned32?  For these 6-8 options described
above an octet or unsigned 16 would already be sufficient.

>     Data Type Semantics: flags

A single TCP packet may contain more than one option.
The list of allowed options is maintained by IANA at
<http://www.iana.org/assignments/tcp-parameters>.
The list already contains 26 entries and TCPM is currently
working on further options.  Therefore, unsigned32
does not appear to be appropriate, because it probaly will
become too small in the very near future.  We should at least
use an unsigned64 data type here.  we can use the IANA-assigned
option number as indicator for the position in the bit field
array for the respective TCP option.

>      content of the IPv4 jumbo payload option.

Fixed.

> - is it important to specify "created for packets of this Flow by an adjacent
>   multicast daemon"
> - regarding to "Note that typically not all of the created packets can be
>   observed at the Observation Point of this Flow.", I'm not sure it makes sense.
>    If you want to say that all IPFIX device wide multicast packets can't be observed,
>    I don't think this is relevant as the observation point is the interface.
>    This is even confusing.

I have no problem with replacing "created" by , for example, "sent".
Do you have another suggestion?

Thanks,

    Juergen

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 20 Jun 2005 16:11:34 +0100

> I renamed it to mplsLabelStackSize and specified 'octets' as unit.

Sorry to labour the point, but surely number of LSEs
is what is important, not number of octets.

> recursively based on mplsLabelStackEntry1.

That would work for me.

- Stewart

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 20 Jun 2005 18:12:42 +0200

> is what is important, not number of octets.

What about just adding mplsLabelStackDepth?
Then we have both cases covered.

>> recursively based on mplsLabelStackEntry1.

OK, I will apply the change if no one else objects.

Thanks,

    Juergen

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 20 Jun 2005 18:10:29 +0100

> Then we have both cases covered.

OK

Stewart

---

From: Benoit Claise <[email-masked]>
Date: Mon, 27 Jun 2005 21:28:01 +0200

Hi Juergen,

Sorry for the delay in replying to you.

>      packet header.

Full stop, new sentence.

> for IPv6 packets, this is the value of the Traffic

>      values are encoded in the first 6 bits of the IPv4 TOS field or

The DSCP value is encoded in ...

>      for specifying a DiffServ Code Point (DSCP) are to be ignored.

I'm not too sure what you by the previous sentence. Which bits are to be 
ignored?
I think your first sentence is enough from a specification point of view.

>      Note that ignoring these bits may be relevant when the DSCP serves

We don't want to speak about flow key/flow value in the information model

>      class field, respectively.

The IP Precedence value is ...

>      may be relevant when the IP Precedence serves as Flow Key.

Same remark as before. I think that the first sentence is enough.

>         Bits 3-7: (DC) Don't Care, value is irrelevant.

I don't see why we should speak about the 8 bits.
I think we should say: "the value of the fragmentation bits of the IPv4 
header, as specified in "Flags" fields of RFC791.

>   Data Type Semantics: flags

This should be an identifier.

>   scenario where these are used?

Class of Service in MPLS network, to generate the core traffic matrix 
for capacity planning.
You will find references in RFC3270

> IPv6: actual payload length = packet length - base header length

That's right! Feel free to insert to the description

> than MPLS header.  That's why I renamed it to mplsLabelStackSize.

Fine.

> It should be called accordingly.

What if you don't have IP within MPLS?

> I really missed this one.  Please see above.

Covered above now with your proposal. Fine.

>>        Note: this is 6 bits of DSCP information

Covered above now with your proposal. Fine.

>>     Note: this is the 3 bits of precedence information
Covered above now with your proposal. Fine.

> We have the IP header length.

We need the IPv4 header length in case we don't want to have another 
flow key (protocol)

> I really missed this one.  Please see above.

Covered above now with your proposal. Fine.

> Shall we include them also or limit the option list to the remaining

I would simply copy everything from the Options in RFC791. Otherwise, 
there is a source of confusion.

> Are there more options defined anywhere outside of RFC 791?

This is not relevant. Let's just copy everything.

> above an octet or unsigned 16 would already be sufficient.

The Options value is 24 bits, so 32 bits make sense.
We would have to specify that the top 8 bits are unspecified.

> A single TCP packet may contain more than one option.

That's right, for example from RFC793

    Note that the list of options may be shorter than the data offset
    field might imply.  The content of the header beyond the
    End-of-Option option must be header padding (i.e., zero).

> array for the respective TCP option. 

If you want unsigned64, fair enough.
Anyway, this is the max value, so using a reduced length of 32 bits can 
be enough to start with.

>> - is it important to specify "created for packets of this Flow by an 
what about this one?

> Do you have another suggestion?

Created is better but it doesn't clear the confusion: this is not 
relevant as the observation point is the interface.

Thanks Juergen.