From: Marc Lavine (mlavine@foundrynet.com)
Date: 07/03/03
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