Re: Summary: what to do about INET/CIDR

* Alex Pilosov <alex@pilosoft.com> [001027 21:36]:
> On Fri, 27 Oct 2000, Larry Rosenman wrote:
> 
> > Not necessarily, especially for novices.  Some people may want to
> > store the netmask with the IP of a host (think ifconfig being
> > AUTOGEN'd). 
> For a single host? Or for a network of hosts? But yes, I see your point if
> a single host has x interfaces, and you are autogenerating ifconfig, with
> my proposal, you'd need to insert each network into networks table.
Or a table of Routers, listed by IP's.  I want to be able to
efficently store the interface name, IP, Mask.  With your proposal, I
can't store it as one row in one table.  With Tom's proposal, I can. 

> 
> > > 99% of people who would be storing IP addresses into postgres database
> > > really do not know nor care what is a netmask on that IP. Only people who
> > > would care are ones who store their _internal_ addresses (read: addresses
> > > used on networks they manage).  There is usually a very limited number of
> > > such networks (<1000). 
> > I disagree.  I'm an ISP, and the network engineer for same.  I have a
> > BOATLOAD of Netblocks from ARIN and providers in a BUNCH of sizes.  I
> > need to subnet them out to customers and for internal use.  I like
> > Tom's latest proposal. This one LOSES functionality for ME. 
> Explain how does it lose functionality?
I may need to list an interface in their net, with their netmask, but
not have it in my networks table.  I don't think that the system
should supply a networks table, per se.   I have much more than 1000's
networks in my shop.  Please don't FORCE me to your model.  I like
Tom's proposal, especially from the "least surprise" aspects.  
> 
> > > It makes no sense to have in database both 10.0.0.1/24 and 10.0.0.2/16.
> > > None whatsoever.
> > Not necessarily, especially with RFC1918 addresses, and reuse within
> > different unconnected networks of the SAME enterprise. 
> Makes no sense to have them in one table, anyway, I stand corrected.  
> For people in situation you describe, you can have a second table of
> networks, and second function to look up networks in that table. 
See above.  Please don't force me to your paradigm. 
> 
> > > This does NOT apply to CIDR datatype, as there are real applications (such
> > > as storing routing tables) where you would care about netmask, but won't
> > > care about a host part. 
> > > 
> > > What I am suggesting is we do the following:
> > > a) inet will NOT have a netmask
> > Please DONT.  See above.
> > > 
> > > b) all the fancy comparison functions on inet should be deleted. 
> > > (leave only > >= = <= <)
> > > 
> > Maybe.  I think they should stay, but I'm one lowly network engineer.
> > > c) the only things you can do on inet is to convert it to 4 octets (of
> > > int1), to a int8, and to retrieve its network from a table of networks.
> > > 
> > > d) have a table, 'networks' (or any other name, maybe pg_networks?) which
> > > would have one column 'network', with type cidr.
> > > create table networks (network cidr not null primary key)
> > Why?
> Because netmask is a property of a network, not of an IP address.
> 
> > > e) have a function network(inet) which would look up the address in a
> > > table of networks using longest-prefix-match. I.E. something similar to:
> > No need.  Let the user do it themselves. Similar to what we did for
> > macaddr's back in the summer. 
> Yeah, it can be user-defined (or a contrib), no question about it, and for
> people who have more than one table of networks, it will _have_ to be
> user-defined.
> 
> Actually, that's probably what I'll end up doing on my own. 
> 

-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749