RE: Re: sFlow Datagram Extensibility

From: Peter Phaal (
Date: 09/23/02

  • Next message: Marc Lavine: "Re: Re: sFlow Datagram Extensibility"

    The updated version of SFLOW-DATAGRAM.txt is available at:

    > The special value will do the job, but I'd describe it differently,
    > something like this:
    > - format = 0 single interface
    > value is ifIndex of the interface. A value of
    > 0x3FFFFFFF indicates that there is no input or output
    > interface (according to which field it appears in).
    > This is used in describing traffic which is not
    > bridged, routed, or otherwise sent through the device
    > being monitored by the agent, but which rather
    > originates or terminates in the device itself. In
    > the input field, this value is used to indicate
    > packets for which the origin was the device itself
    > (e.g. a RIP request packet sent by the device, if it
    > is acting as an IP router). In the output field,
    > this value is used to indicate packets for which the
    > destination was the device itself (e.g. a RIP
    > response packet (whether unicast or not) received by
    > the device, if it is acting as an IP router).

    Clearer, I've incorporated your suggested text.

    > I view the information about a discard having occurred on
    > input or output as
    > pretty architecture-independent, although the interpretation of that
    > information would be architecture-dependent. I guess we can
    > always add a
    > vendor extension if we need this information, though.

    Adding this information as a vendor extension, or even as a standard sFlow
    data record would be possible without having to change SFLOW-DATAGRAM
    version. A detailed discard record could even have a reference to the
    particular ACL entry that caused the discard.

    > Yes, the ICMP destination unreachable codes do provide a
    > detailed set of
    > reasons for unreachability. Here's a modified version of part of that
    > section, with some additional explanatory text that I suggest
    > including:
    > 0 - 255 use ICMP Destination Unreachable codes
    > See for authoritative list.
    > RFC 1812, section describes the
    > current codes. Note that the use of
    > these codes does not imply that the
    > packet to which they refer is an IP
    > packet, or if it is, that an ICMP message
    > of any kind was generated for it.
    > Current values are:
    > I think there should also be a code to indicate that a packet
    > was too big to
    > be forwarded to its destination (for non-IP packets, since
    > code 4 seems a
    > little too IP-specific to apply), such as:
    > 262 = packet too big (for protocols that don't support
    > fragmentation)
    > Also, while we use the term "rate limiting", the term
    > "traffic shaping" may
    > be more commonly used, so I suggest including both terms:
    > 261 = traffic shaping/rate limiting

    Good suggestions. I've incorporated them in the text.


    This archive was generated by hypermail 2.1.4 : 09/23/02 PDT