Re: Encoding unknown addresses in sFlow datagrams

From: Marc Lavine (mlavine@foundrynet.com)
Date: 07/03/03

  • Next message: Peter Phaal: "RE: Encoding unknown addresses in sFlow datagrams"

    Adding the UNKNOWN value to the address_type enum seems fine to me.

    For the extended_router structure's nexthop field, my thinking is that for
    routes to directly-connected subnets, the nexthop field should have the
    value 0.0.0.0 for IPv4, or ::0 for IPv6, as appropriate. This seems
    preferable to me to using the old MIB-2 definition, where the IP address on
    the outgoing interface is used, since using the all-zeroes addresses makes
    it easy to determine if a route was to a directly-connected subnet, without
    having to correlate the information with a list of all of the device's IP
    addresses.

    This would also be consistent with RFC 2096, as you mentioned, and with RFC
    2465, which defines the corresponding IPv6 MIB:

    ipv6RouteNextHop OBJECT-TYPE
        SYNTAX Ipv6Address
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
          "On remote routes, the address of the next
          system en route; otherwise, ::0
          ('00000000000000000000000000000000'H in ASN.1
          string representation)."
        ::= { ipv6RouteEntry 5 }

    Also, on another, minor issue, I suggest renaming the src_mask and dst_mask
    fields in the extended_router structure to something like src_mask_len (or
    _length) and dst_mask_len. I think that would make it clearer that they
    should contain the lengths of the masks, rather than the masks themselves.

    Marc

    ----- Original Message -----
    From: "Peter Phaal" <peter.phaal@inmon.com>
    To: "'Marc Lavine'" <mlavine@foundrynet.com>; <sflow@sflow.org>
    Sent: Tuesday, July 01, 2003 9:35 AM
    Subject: RE: [sFlow] Encoding unknown addresses in sFlow datagrams

    > I wasn't thinking of any particular situation. It just seems prudent to
    > define an unknown value for address so that the condition is well defined.
    > It makes the address definition more useful for future extensions and in
    > vendor specific structures where a undefined value may be more applicable.
    >
    > As far as the current set of sFlow structures is concerned, address is
    > currently used to encode nexthop values in the extended_router,
    > extended_gateway, extended_mpls structures and in the extended_nat
    > structure.
    >
    > In the case of a directly connected subnet, the IP address of the next hop
    > should probably be consistent with the MIB-2 definition of ipRouteNextHop:
    >
    > "The IP address of the next hop of this route.
    > (In the case of a route bound to an interface
    > which is realized via a broadcast media, the value
    > of this field is the agent's IP address on that
    > interface.)"
    >
    > The only case I can think of where the nexthop might not be known would be
    a
    > statically defined route to an unnumbered interface.
    >
    > RFC 2096 (IP Forwarding Table MIB) anticipates that the nexthop might not
    be
    > known, and defines an unknown ipCidrRouteNextHop as 0.0.0.0. However, RFC
    > 2046 uses the IpAddress type from SNMPv2-SMI and so only deals with IPv4
    > addresses. Since the sFlow address type supports IPv6 it seems more
    > appropriate to explicitly encode the unkown value, rather than return an
    > IPv4 address where an IPv6 address was expected.
    >
    > Peter
    >
    > > -----Original Message-----
    > > From: owner-sflow@inmon.com [mailto:owner-sflow@inmon.com]On Behalf Of
    > > Marc Lavine
    > > Sent: Monday, June 30, 2003 4:59 PM
    > > To: peter.phaal@inmon.com; sflow@sflow.org
    > > Subject: Re: [sFlow] Encoding unknown addresses in sFlow datagrams
    > >
    > >
    > > Peter,
    > >
    > > Is this for directly connected subnets, or is there some
    > > other case you have
    > > in mind?
    > >
    > > Marc
    > >
    > > ----- Original Message -----
    > > From: "Peter Phaal" <peter.phaal@inmon.com>
    > > To: <sflow@sflow.org>
    > > Sent: Thursday, June 26, 2003 11:25 AM
    > > Subject: [sFlow] Encoding unknown addresses in sFlow datagrams
    > >
    > >
    > > > Currently there is no specified way to encode an unknown
    > > address (for
    > > > example, the next_hop address may not be known for a static route).
    > > >
    > > > One could specify that an IPv4 address of 0.0.0.0 means
    > > unknown, although
    > > > this may be a little obscure, especially if returned by an
    > > IPv6 router. An
    > > > explicit unknown value is preferable and can easily be
    > > defined as follows:
    > > >
    > > > /* Address types */
    > > >
    > > > typedef opaque ip_v4[4];
    > > > typedef opaque ip_v6[16];
    > > >
    > > > enum address_type {
    > > > UNKNOWN = 0,
    > > > IP_V4 = 1,
    > > > IP_V6 = 2
    > > > }
    > > >
    > > > union address (address_type type) {
    > > > case UNKNOWN:
    > > > void;
    > > > case IP_V4:
    > > > ip_v4;
    > > > case IP_V6:
    > > > ip_v6;
    > > > }
    > > >
    > > > Comments?
    > > >
    > > > Peter
    > >
    >



    This archive was generated by hypermail 2.1.4 : 07/03/03 PDT