Subject: [ipfix] draft-ietf-ipfix-info-03 - comments

From: Stewart Bryant <[email-masked]>
Date: Wed, 18 Feb 2004 18:20:27 +0000

Juergen

Some comments re draft-ietf-ipfix-info-03:

4. Flow Attributes

4.1 octetCount

    Description: The number of observed octets.

    Abstract Data Type: unsigned64

    Field Id: 1

    Units: octets

SB> Why remove the distinction between in and out?
SB> Many observers will be in routers or other packet
SB> processors, and removing the distinction means
SB> correlating the results of two observers, when
SB> in practise only one is needed reporting input
SB> and output characteristics.

4.2 packetCount

    Description: The number of observed packets.

    Abstract Data Type: unsigned64

    Field Id: 2

    Units: packets

SB> As 4.1

4.5 classOfService

SB> For compatibility with Netflow, this should just be
SB> IP CoS. Can we restrict the definition to IP and create
SB> new objects for MPLSS and VLAN?
    Description:

       The class of service.

       The definition of classOfService is dependent on the protocol
       being observed. Those considered here are:

       *  For IPv4 packets the class of service is given by the value of
          the type of service field in the IPv4 packet header.

       *  For IPv6 packets the class of service is given by the value of
          the traffic class field in the IPv6 packet header.

       *  For MPLS the class of service is given by the value of the
          experimental use (Exp) field in label stack entries. The Exp
          field has a length of 3 bits.  These are mapped to the three
          least valued bits of the classOfService octet.  All other bits
          of the octet are set to zero.

       *  For VLAN the class of service is given by the value of the type
          of the user_priority field as defined in IEEE802.1q[802.1q] and
          IEEE 802.1p[802.1p].

       EDITORS' NOTE: THIS NEEDS FURTHER WORK

    Abstract Data Type: octet

    Data Type Semantics: identifier

    Field Id: 5

    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 3032
       for the definition of the Exp field in label stack entries. See

SB> I think that we also need to call up diffserv

4.7 sourcePort

SB> This would be less ambiguous if it were called
SB> transportSourcePort

4.9 sourceMask

    Description: The number of contiguous bits that are relevant in the
       source address field of the IP packet header (i.e. the subnet mask
       in slash notation).

SB> This is the IPv4 Mask in Netflow which as a seperate
SB> IPv6 Mask (id 29). Since this is part of the compatibility
SB> list it should retain the NF definition. If this is unacceptable
SB> then perhaps we need to define a new IE type of generic mask.

4.11 destinationPort

SB> Again this would be less ambiguous if called
SB> transportDestinationPort

4.13 destinationMask

    Description:

       The number of contiguous bits that are relevant in the destination
       address field of the IP packet header (i.e. the subnet mask in
       slash notation).

SB> Again in NF this is the IPv4 mask

    Abstract Data Type: octet

    Field Id: 13

    Units: bits

SB> Again there is the issue of directionality, and NF 24 and
SB> 25 define output counts. I think that this is a useful
SB> compression of data.

4.25 anotherSourceMask

SB> IPv6
SB> I think that we need to take advisment from the IPv6
SB> NF team before deleting. Remember that IPv6 has various
SB> transation and compatibility modes

    Description:

       The number of contiguous bits that are relevant in the source
       address field of the IP packet header (i.e. the subnet mask in
       slash notation).  This redundant field has the same semantics as
       field 9.

    Abstract Data Type: octet

    Field Id: 29

    Units: bits

4.26 destinationMask
SB> As above

4.27 flowLabel

SB> I think that this should have a V6 somewhere in it's name

4.28 icmpTypeCode

    Description: Type and Code of the ICMP message.

    Abstract Data Type: unsigned16

    Field Id: 32

    Reference: See RFC 792 for a definition of the ICMP type and code
       fields.

SB> This needs some encoding info, because it's technically
SB> two octet fields in the header that are concatentated.
SB> I suggested making reference to network byte order.

4.31 samplingAlgorithm

    Description:

       The following sampling algorithms are defined:

       *  1 Deterministic sampling

       *  2 Random Sampling

       *  3 Time-based sampling

SB> As I recall Benoit suggested that #3 be deleted

SB> NF has IPv4 source prefix #44
SB> NF has IPv4 destination prefix #45
SB> Please can we include them so that if they are needed
SB> in future we do not have a duplicate definition.

SB> #46 and #47 are MPLS parameters in NF. These were
SB> deleted along with the other MPLS parameters in the
SB> list I supplied.
SB>
SB> Why are we not listing MPLS parameters?
SB>
SB> Also you have not included #55 destination CoS
SB> Again an observer may be placed at a point where
SB> this has been changed as part of a processing
SB> operation.
SB>
SB> You also miss out MAC and VLAN elements from the
SB> list. I know of cases where such information is
SB> vital to the policing and forensics of an IP network.
SB>

4.37 ipVersion

    Description: The IP version field given in the IP header.

    Abstract Data Type: octet

    Field Id: 60

    Units: flows

    Reference:

       See RFC 791 for a definition of the version field in the IPv6
       packet header. See RFC 2460 for a definition of the version field
       in the IPv6 packet header. Additional information on defined
       version numbers can be found at http://www.iana.org/assignments/
       version-numbers.

SB> #61 you miss out direction

4.38 ipNextHopAddressV6

    Description: The IPv6 address of the next IP hop to which packets are
       forwarded.

    Abstract Data Type: ipv6Address

    Field Id: 62

4.39 bgpNextHopAddressV6

    Description: The IPv6 address of the next BGP hop to which packets
       are forwarded.

    Abstract Data Type: ipv6Address

    Data Type Semantics: identifier

    Field Id: 63

    Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
       definition of the AS number.

SB> I know that the definition is scruffy, but 64 is the NF
SB> method of reporting IPv6 options. This will be needed in some
SB> form or other.

SB> #70 to #79 are the MPLS label stack. Why are they
SB> omitted?

4.44 droppedOctetCount

    Description: The number of octets dropped.

SB> We need a more complete definition for this
SB> Same for 85

SB> Again I included an MPLS IE at 85 that has been dropped

SB> Text also needs to make reference to the fact
SB> that 1 to 79 inc are reserved for NF and must
SB> not be redefined, or at least not allocated
SB> by IANA. As things stand it looks like IANA
SB> is free to fill in the gaps.

- Stewart

--
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: Juergen Quittek <[email-masked]>
Date: Thu, 19 Feb 2004 00:08:23 +0100

Stewart,

Many thanks for so many comments!
Please seesome replies inline.

> SB> and output characteristics.

But then you would have two observation points.
This does not match our current architecture.
Still you can report a flows input interface
and its output interface.

Am I missing something?

> SB> new objects for MPLSS and VLAN?

That's fine with me.

> SB> I think that we also need to call up diffserv

Yes. I had it in and I do not know how it got lost.

> SB> This would be less ambiguous if it were called

Agreed.

> SB> then perhaps we need to define a new IE type of generic mask.

I never understood the separation of V4 mask and v6 mask.
Do you have a good reason for this?
Without one I would prefer the general mask serving both IP versions.

> SB> transportDestinationPort

Again fine with me.

> SB> Again in NF this is the IPv4 mask

What would be the problem if we apply it to v6?

> SB> 25 define output counts. I think that this is a useful

Yes. Let's solve the in/out discussion above.

> SB> transation and compatibility modes

Does the description still match?

> SB> I think that this should have a V6 somewhere in it's name

Fine.

> SB> I suggested making reference to network byte order.

We do not have a byte order in the abstract data model.
But you are right: this is ambiguous.  We should state
that the value is 256*type + code.

> SB> in future we do not have a duplicate definition.

Yes, there were several NF fields that I did not include,
because of the limited time for editing the draft.
Particularly, I did not include fields for which I
needed some more discussion.

Let's discuss all missing ones in Seoul.

> SB> #61 you miss out direction

Yes, I'd like to discuss this as well.

> SB> method of reporting IPv6 options. This will be needed in some

Agreed.

> SB> #70 to #79 are the MPLS label stack. Why are they

Again, just a bit of discussion needed.

> SB> is free to fill in the gaps.

I want to explicitly list the gaps after we have completed
discussion on all NF fields.

> - Stewart

Thanks again,

    Juergen

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 19 Feb 2004 14:40:17 +0000

Juergen

Some comments on some of your comments on my comments :)

> and its output interface.

My concern is that you need to identify and correlate two
observation points.

Supposing, for example, you are monitoring a data-compression
system. It might be reasonable to ask what level of compression
you are getting on flows through it.

With one observation point able to monitor both directions
it's easy. With two you have to correlate based on information
in the flow records. With two and sampling, I don't think
that it is possible.

> Without one I would prefer the general mask serving both IP versions.

I am in the process of finding out why we did this, and will
get back to you. If there is no good reason we should move
one set to historic. In the meanwhile can we capture the
issue so that it does not get forgotten.

One reason that someone noted in passing was that the validation
rules in the collector would be different (different max length)

> Does the description still match?

No, it is explicity v6. The NF code definately puts v6 masks
here and v4 masks in IE#9

> that the value is 256*type + code.

That would be fine with me

>> SB> As I recall Benoit suggested that #3 be deleted

Please don't loose this above comment in the noise.

> Let's discuss all missing ones in Seoul.

I appreciate the time difficuly, and acknowledge that I was
late giving you the info. Let discuss in Seoul.

> discussion on all NF fields.

I think that it is useful to list them as pro-formas until
the last minute, firstly because it forces us to consider them
and secondly it is a double check that there are no typos
in the IE numbers (because the numbers match the heading numbers)

- Stewart