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

[Terry Manderson <[e-mail]>]

Hi Jeff,

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


On 3/08/10 7:56 AM, "Jeffrey Haas" <[e-mail]> wrote:

> 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.
> 

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


> 
> 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.
> 

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