From: Peter Phaal (peter.phaal@inmon.com)
Date: 07/03/03
Marc,
Good suggestions, I've incorporated them in a new draft of the
SFLOW-STRUCTS.txt,
http://www.sflow.org/drafts/draft12/SFLOW-STRUCTS.txt
Peter
> -----Original Message-----
> From: owner-sflow@inmon.com [mailto:owner-sflow@inmon.com]On Behalf Of
> Marc Lavine
> Sent: Thursday, July 03, 2003 2:44 AM
> To: peter.phaal@inmon.com; sflow@sflow.org
> Subject: Re: [sFlow] 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
This archive was generated by hypermail 2.1.4 : 07/03/03 PDT