From: Peter Phaal (peter_phaal@inmon.com)
Date: 09/23/02
The updated version of SFLOW-DATAGRAM.txt is available at:
http://www.sflow.org/drafts/draft5/SFLOW-DATAGRAM.txt
> 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 www.iana.org for authoritative list.
> RFC 1812, section 5.2.7.1 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.
Regards,
Peter
This archive was generated by hypermail 2.1.4 : 09/23/02 PDT