Subject: [GROW] Comment on draft-manderson-grow-geomrt-00

From: Jeffrey Haas <[email-masked]>
Date: Mon, 2 Aug 2010 21:56:01 +0000

I just got done re-reading this draft.  Upon review, I'm wondering if
instead of creating a new type that simply adding a new sub-type may be
more appropriate.

The current proposal effectively replaces the current PEER_INDEX_TABLE with
a new one that has the WGS84 records.  Consider instead that a new sub-type
table is defined which has a similar structure to the PEER_INDEX_TABLE.  It
would simply provide a matching augmentation of the PEER_INDEX_TABLE by
carrying the geo records.

This has the advantage that it requires fewer changes to existing
implementations.  In particular, it permits older MRT file readers to be
able to continue to parse the dump data.  Only the new geoip information
would be opaque.

-- Jeff

---

From: Terry Manderson <[email-masked]>
Date: Wed, 11 Aug 2010 20:32:25 -0700

Hi Jeff,

Apologies for the lag. I selfishly engaged in a personal life after ietf.

> instead of creating a new type that simply adding a new sub-type may be

I considered that early on in the piece as the peer_index_table was the only
item augmented. And it made logical sense. :-) ie the subtypes might be:

       1    PEER_INDEX_TABLE
       2    RIB_IPV4_UNICAST
       3    RIB_IPV4_MULTICAST
       4    RIB_IPV6_UNICAST
       5    RIB_IPV6_MULTICAST
       6    RIB_GENERIC
       7    GEO_PEER_TABLE

> able to continue to parse the dump data.  Only the new geoip information

The experience I had is that my tests with some MRT readers ended in code
crashes when using sub-types that weren't natively known. (not all crashed
mind you, the old faithful zebra-dump-parser.pl has a nice sane warn "TYPE:
MSG_TABLE_DUMP_V2/UNKNOWN_SUBTYPE_$subtype\n";)

So to be safe I opted for a peer_index_table replacement and a new file/dump
altogether (and nomenclature) as almost all code bases exited nicely enough
when the type was unknown.

A part of the justification for an almost 'all or nothing' approach is that
of the few I asked most people would rather consciously choose to output
(and therefore read) an augmented dump with geo-loc info.

What say the list? bundle in geo-loc under the exiting TABLE_DUMP_v2 with an
additional subtype or have a specific FCFS type TABLE_DUMP_v2+GEO? I can go
either way on this.

Cheers
Terry