Erik Romijn wrote:
Hello Larry, John,
On Tue, Jan 23, 2007 at 01:22:12AM +0000, john heasley wrote:
Mon, Jan 22, 2007 at 03:12:55PM -0500, Larry J. Blunk:
I was asking whether we need
to include the local (collector's) IP and AS number in addition
to the peer's IP and AS number. This information is included
in the BGP4MP_ENTRY type. I suspect this information is
not really needed and would simply bloat the dump files further.
Shouldnt the file be stand-alone? not require previous knowledge of it's
source and yet be able to differentiate dumps of one source from another?
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.
But given the current format of one MRT record per table entry,
it would add considerable bloat (particularly if the collector has
a 32-bit AS number and an IPv6 IP address). The Routeviews
table dumps are already unwieldy enough as is, I'd really hate
to make them any worse.
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. It's
useful to know if a dump came from a Routeviews collector or the
RIS RRC01 collector, but I don't much care what IP/AS number
the Routeviews or RIS collector happened to be using.
That said, we could perhaps define an initial header MRT
record for table dumps that includes the collector's IP and
AS number and perhaps an indexed array of peer IP/AS
numbers. By using a 16-bit array number for a peer
instead of the IP/AS number in each MRT dump record,
you could cut down on the size of the table dumps
considerably (particularly as peers move to IPv6 addresses
and 32-bit AS numbers). This initial header record could
be generated and written to the beginning of each table
dump file.
Below is a proposed TABLE_DUMP_NEW type. The
View and Status fields have been dropped
What about a router with multiple bgp instances?
I think quagga can do this, don't know of any other bgpd.
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)
Yes, quagga supports views (bgp multiple-instance). However,
they are named, not numbered, and quagga always hardcodes the
View field in MRT TABLE_DUMP's to be 0. There are a couple
of ways to handle views. Either through file-naming of the
generated dump file, or by having a field in an initial header
MRT record as suggested above.
Don't understand the comment about Peer IP and AS as those
are already in the record.
[..] 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.
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.
-Larry
_______________________________________________
GROW mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/grow
