On Thu, Jul 07, 2011 at 09:51:39AM -0400, Larry Blunk wrote: > On 07/07/2011 07:37 AM, Nick Hilliard wrote: > >> This document describes the MRT format for routing information > >> export. This format was developed in concert with the Multi-threaded > >> Routing Toolkit (MRT) from whence the format takes it name. The > >> format can be used to export routing protocol messages, state > >> changes, and routing information base contents. > > > >Similar to BMP, MRT uses 32 bit timestamps. > > > >Once again, the issue is a question of whether to take a pain hit now, > >while MRT still has a relatively small install base, or whether to take a > >much, much bigger pain hit when we reach 2038 when we have much wider > >deployment of MRT + a whole pile of archived records to deal with (as we're > >talking about an archive storage mechanism here). > > > >Personally, I'm not a fan of kicking cans down the road. > > > >The standard also lacks a version field in the headers. If the authors > >were to decide that changing the header might be in the protocol's > >long-term interest, then adding a version field would probably be a good > >idea. > > > >Nick > >[as with my previous comments on the BMP ID, apologies for jumping in with > >a fundamental change suggestion like this on a -15 draft.] > >_______________________________________________ > > > Nick, > These issues were brought up in the IESG last call (lack > of version number + 32 bit timestamps). Rather than > attempting to apply more band-aids to the specification, > a decision was made that a clean slate design would be > a better choice and the draft was changed from Standards > Track to Informational. There's an expired draft with > a proposed XML based format -- > http://tools.ietf.org/html/draft-cheng-grow-bgp-xml-00 > with an implementation available at > http://bgpmon.netsec.colostate.edu/ >
I hope this is more of a joke than something taken seriously. The RIPE provided MRT V2 table dumps are around 400MB each. The V2 table dump format tries to be as compact a possible whereas this XML format is super verbose (the shown keepalive is around 1000 bytes instead of 19 and an update will be easily in the 10k range). Also parsing XML will probably take magnitudes more times and the needed memory and disk space will make analysing and archiving a painful task. IMO this proposal is unusable for the real world. -- :wq Claudio _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
