On Tue, Jan 23, 2007 at 11:32:28AM -0500, Larry J. Blunk wrote: > Erik Romijn wrote: > >You have a point there. If one takes dump files from random sources, it > >is not possible to determine where they came from. > > > >On the other hand, it would add bloat... > > > If the table dumps were done in a single atomic MRT record > (something I've thought about), I think this would be reasonable. > [...] > I don't think people are generally in the habit of pulling down > table dumps from random unknown sources. And in the end, > the IP/AS of the collector is not terribly critical information.
I agree. Let's not bloat it more. > That said, we could perhaps define an initial header MRT > record for table dumps that includes the collector's IP and > AS number That may be useful. But still, there is your good point that people will not fetch random dumps and then try to find out where they came from. > perhaps an indexed array of peer IP/AS numbers. Nice idea. But how much would we save? Let's assume asn16/ipv4, so 48 bits of IP/AS per entry. With a bit more than 200K routes that's 10Mbit of IP/AS. With the index, assuming a 16-bit number and 200 peers, it would be 9600 bits of array and 3.2M of indexes. So that's 33% cut (on peer information only). We save about 0.85Mbyte here. A RIS RIB dump on the biggest machine is 240M uncompressed. So we would save 0.35%. Assuming best-case, ipv6/asn32. Without array 30Mbit, so that's 0.7% save based on RIS examples. With an 8-bit index it's 0.7% for asn16/ipv4 and 1.4% for asn32/ipv6. However, the latter allows only 255 peers. So the reduction in data is really small. Unless I miscalculated ofcourse :-) > >>> The View and Status fields have been dropped > >>> > > > >What about a router with multiple bgp instances? > >Wasn't the views field intended to be able to make the distinction > >between entries from the different bgp instances? > > > >(this is also solved by adding Peer IP and AS) > Don't understand the comment about Peer IP and AS as those > are already in the record. I mixed up. I was referring to the collector's own IP and AS, which doesn't make any sense either. Forget that comment :-) > >>>[..] peer AS size (16 or 32 bit) [..] > >>> > >>why bother with 2 byte ASNs? > >> > > > >Indeed. Why not make Peer AS always 4 bytes? > > > > Again, bloat. There's plenty of bits available in the subtype > code field, why not use them? Lot's less CPU cycles/time > to do a simple bit test for field size than to transfer around > and decompress unneeded bits. I must have missed somewhere that asn16/asn32 would be encoded in the subtype field. And yes, if we store the bits (subtype) anyway, your idea is a lot more efficient as we won't have much asn32* for the coming time. > >And if we stick to this, how would a parser know the boundary between > >peer AS and Prefix Length? > > Bits are defined in the subtype code to define both peer > IP address size and AS number size. You know where the > Prefix Length field begins based on the size of the peer's > IP address and AS number. Ofcourse. If it's encoded in the subtype, the answer to my question is very obvious :-) * Probably the correct term here should be "4-byte only AS", as AS2134 can be used on an asn32 BGP implementation too, but would be stored as 16-bit number. cheers, -- Erik Romijn RIPE NCC jr. software engineer http://www.ripe.net/ Information Services dept.
pgp3qUh6acBKm.pgp
Description: PGP signature
_______________________________________________ GROW mailing list [email protected] https://www1.ietf.org/mailman/listinfo/grow
