RE: Re: sFlow Datagram Extensibility

From: Peter Phaal (peter_phaal@inmon.com)
Date: 09/18/02

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

    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.

    Peter_Phaal@inmon.com



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