Hi Jeff, Apologies for the lag. I selfishly engaged in a personal life after ietf.
On 3/08/10 7:56 AM, "Jeffrey Haas" <[email protected]> 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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
