On Thu, Jan 25, 2007 at 09:37:18AM +0100, Erik Romijn wrote: > On Wed, Jan 24, 2007 at 12:17:36PM +0100, Erik Romijn wrote: > > > > On Wed, Jan 24, 2007 at 12:06:04PM +0100, Erik Romijn wrote: > > > On Tue, Jan 23, 2007 at 11:32:28AM -0500, Larry J. Blunk wrote: > > > > perhaps an indexed array of peer IP/AS numbers. > > > > > > Nice idea. But how much would we save? > > > [..] > > > We save about 0.85Mbyte here. A RIS RIB dump on the biggest machine is > > > 240M uncompressed. So we would save 0.35%. > > > > I'm mixing up again here. That RIS RIB dump is not 200K routes, that > > would be a FIB dump. The RIB dump is approximately 30M entries. > > No it's not, it's 3M entries. Without indexing 18MB of peer info data, > with indexing 6MB. > Save of 12MB of 240, so 5% saving. > > [Don't try to multiply numbers without a calculator right before lunch]
To finalize, as I don't see any further comments (yet), I think we should not use this indexed array of peer data. Which, if I read all discussion correctly, brings us to the format as initially suggested by Larry. One last thing to clarify there: in which order are the bits in the subtype, and what values mean what. I assume Larry meant (and if not I propose): 0 - unset for IPv4, set for IPv6 1 - unset when AS field is 16 bits, set when it's 32 bits 2 - unset for IPv4 unicast, set for multi-protocol (I explicitly avoided "asn32" or "4-byte only AS" here, as AS5 or AS100 may be stored in a 32bit field just as well.) Also, I have one last comment: is it smart to call this type TABLE_DUMP_NEW? What happens when we update it again? TABLE_DUMP_NEWER? And then TABLE_DUMP_NEWER_THAN_THE_PREVIOUS_NEWER? :-) cheers, -- Erik Romijn RIPE NCC jr. software engineer http://www.ripe.net/ Information Services dept.
pgpRxQ4s7zzPh.pgp
Description: PGP signature
_______________________________________________ GROW mailing list [email protected] https://www1.ietf.org/mailman/listinfo/grow
