From: Marc Lavine (mlavine@foundrynet.com)
Date: 09/23/02
> A new header protocol wouldn't trigger a change in the datagram version
> since there is no reference to header_protocol in the SFLOW-DATAGRAM
> definition.
Oops, yes, you're right; it wouldn't affect the datagram version.
> However, it is worth making it clear that new header_protocols
> can be defined, so I've added the following language to SFLOW-STRUCTS:
>
> /* The header_protocol enumeration may be expanded over time.
> Applications receiving sFlow must be prepared to receive
> sampled_header structures with unknown sampled_header values.
>
> The authoritative list of protocol numbers will be maintained
> at www.sflow.org */
Looks fine. (The reason I focused on the header_protocol is that XDR
considers it an error to encode a value for an enum that doesn't match the
ones that were specified.)
> > It would probably be good to state explicitly whether this is
> > the total
> > number of drops since the agent was initialized (I presume)
> > or since the
> > previous sample. Also, does this field qualify for the
> > special counter
> > behavior described above if it is not supported?
>
> How about:
>
> unsigned int drops; /* Number of times that the sFlow agent
> detected that a packet marked to be
> sampled was dropped due to
> lack of resources. The drops counter
> reports the total number of drops
> detected since the agent was last
> reset.
> A high drop rate indicates that the
> management agent is unable to process
> samples as fast as they are being
> generated by hardware. Increasing
> sampling_rate will reduce the drop
> rate. Note: An agent that cannot
> detect drops will always report
> zero. */
>
> Given the definition of drops it seems that an agent that cannot detect
> drops should always report zero. No agent is likely to provide a complete
> tally of drops and the definition acknowledges that a drop is counted only
> when it can be detected.
Okay.
> > This doesn't quite address the original case I was asking
> > about, which is
> > that there could be an output port with no input port, or an
> > input port with
> > no output port, and neither of these imply that the packet
> > was dropped, but
> > rather that it was sent to or from the device itself (rather
> > than through
> > the device). Some examples would be a routing protocol
> > packet, such as a
> > RIP or BGP packet, or a spanning tree protocol BPDU, or a
> > telnet packet,
> > etc. To describe this, I suggest that additional codes are
> > needed in both
> > the input and output fields to indicate "no interface" (which
> > I think should
> > be distinct from "unknown").
>
> Does this address your requirement?
>
> - format = 0 single interface
> value is ifIndex of the interface. A value of
> 0x3FFFFFFF indicates an interface without an assigned
> ifIndex (for example, the management entity within the
> device may not have an assigned ifIndex. In this case,
> routing protocol and network management traffic would
> be associated with the unassigned interface).
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).
> > I do think that adding the type of information that you've
> > sketched out
> > above is a good thing, in that it could allow for more completely
> > characterizing what's happening to the traffic. Placing the
> > discard codes
> > into the output field, precludes capturing some of the
> > information, however.
> > I know that with our switches, some features, such as ACLs
> > can be applied to
> > traffic on input or output. For a packet discarded due to an
> > output ACL, I
> > can imagine that one might want to be able to know which
> > interface it would
> > have gone out through had it not been discarded. If you
> > think that this is
> > useful and want to allow for the possibility of capturing
> > that information
> > in the protocol, then it would seem to me that one could add
> > an additional
> > field, perhaps called "disposition", that could describe
> > whether the packet
> > was processed normally, or whether it was discarded at input
> > or at output,
> > and the reason. Presumably, most packets aren't discarded on
> > output, so if
> > one wished to not add extra overhead to the structure for
> > every sample,
> > another option would be to define an extended data structure
> > to hold the
> > additional data (e.g. which output port would have been used
> > (assuming that
> > the agent implementation can support this, of course)).
>
> I am not sure that details of whether a packet was discarded by an input,
or
> an output ACL (and possibly which ACL caused the discard) belongs here.
This
> type of information seems very architecture dependent.
>
> The basic idea with the input/output information is to treat the device as
a
> black box. Packets go in and come out (unless they are discarded) and the
> flow record tells you the ingress/egress without being too particular
about
> what happened within the box. Detailed information on discarded packets
> seems like a good candidate for a vendor extension.
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.
> The ICMP Destination Unreachable codes give a pretty good initial set of
> codes. How about?
>
> - format = 1 packet discarded
> value is a reason code. Currently the following codes
> are defined:
> 0 - 255 use ICMP Destination Unreachable codes
> See www.iana.org for authoratative list.
> Current value are:
> ...
> 256 = unknown
> 257 = ttl exceeded
> 258 = ACL
> 259 = no buffer space
> 260 = RED
> 261 = rate limiting
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
> Your suggestion made me look again at the XDR specification and I noticed
> that the user data needed to be encoded as an opaque<>, not a string<>
> (String is defined as an ASCII string).
Good catch.
> /* Character Set
> MIBEnum value of character set used to encode a string - See RFC 2978
> Where possible UTF-8 encoding (MIBEnum=106) should be used. A value
> of zero indicates an unknown encoding. */
>
> typedef unsigned int charset;
>
> /* Extended User Data */
> /* opaque = flow_data; enterprise = 0; format = 1004 */
>
> struct extended_user {
> charset src_charset; /* Character set for src_user */
> opaque src_user<>; /* User ID associated with packet source */
> charset dst_charset; /* Character set for dst_user */
> opaque dst_user<>; /* User ID associated with packet
destination
> */
> }
Looks good.
Regards,
Marc
This archive was generated by hypermail 2.1.4 : 09/23/02 PDT