From: Peter Phaal (peter_phaal@inmon.com)
Date: 09/18/02
New drafts of the structures are available at:
http://www.sflow.org/drafts/draft4/SFLOW-DATAGRAM.txt
http://www.sflow.org/drafts/draft4/SFLOW-STRUCTS.txt
> Here's a suggested rewording to make the first sentence
> clearer about who is
> allowed to extend a structure, and to make the last sentence
> a little more
> explanatory:
>
> Note: An enterprise which has defined sFlow structures is
> permitted to extend those structure definitions at the end
> without changing structure numbers. Any changes that would
> alter or invalidate fields in published structure
> definitions must be implemented using a new structure
> number. This policy allows additional data to be added to
> structures while still maintaining backward compatibility.
> Applications receiving sFlow data must always use the
> opaque length information when decoding opaque<> structures
> so that encountering extended structures will not cause
> decoding errors. Note that these rules apply to the
> standard structures as well.
>
Much clearer.
> Also, on a related issue, do you think there should be a
> statement that some
> enumerated values may be extended by a revision of the
> standard, without
> changing the datagram version number? By this, I'm thinking,
> most notably,
> that adding a new header_protocol value, should the need
> arise, should not
> require creating datagram version 6.
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. 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 */
I did take a look at SFLOW-DATAGRAM to see if there were other lists that we
might want to expand without changing the version number. I added language
to the description of the discard codes to make it clear that new codes
could be defined.
> 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.
> 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).
> 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.
> Regarding the specific discard codes, I'd suggest adding
> something like
> "rate limiting". Also, would "no route to dest." include not
> being able to
> get an ARP response from a destination node on a local
> subnet? If so, then
> perhaps we could just call it "destination unreachable".
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:
0 Net Unreachable
1 Host Unreachable
2 Protocol Unreachable
3 Port Unreachable
4 Fragmentation Needed and
Don't Fragment was Set
5 Source Route Failed
6 Destination Network Unknown
7 Destination Host Unknown
8 Source Host Isolated
9 Communication with Destination
Network is Administratively
Prohibited
10 Communication with Destination Host
is Administratively Prohibited
11 Destination Network Unreachable for
Type of Service
12 Destination Host Unreachable for
Type of Service
13 Communication Administratively
Prohibited
14 Host Precedence Violation
15 Precedence cutoff in effect
256 = unknown
257 = ttl exceeded
258 = ACL
259 = no buffer space
260 = RED
261 = rate limiting
Note: Additional reason codes may be published over
time. An application receiving sFlow must be
prepared to accept additional reason codes.
The authoritative list of reason codes will
be maintained at www.sflow.org
> So as to not preclude any particular agent implementation, I
> think it would
> be good to have charsets for the source and destination users
> specified
> independently. This would allow for the possibility of the
> information
> about the two users coming from different sources. Also, for this
> particular case, it might be worthwhile to explicitly state
> that zero should
> be specified for a charset if it is not known.
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).
/* 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
*/
}
Regards,
Peter
----------------------
Peter Phaal
InMon Corp.
This archive was generated by hypermail 2.1.4 : 09/18/02 PDT