On Jun 24, 2010, at 11:13 AM, Larry Blunk wrote: > I recall that John did initially look at the MRT format, but > ran into some issues. Unfortunately, I don't quite remember > what they were. John should be able to detail the issues.
That was quite a while ago so my memory of details is pretty fuzzy. Glancing through draft-ietf-grow-mrt-11 I see that there is a significant (say, 80%) syntactic overlap between MRT's BGP4MP_MESSAGE_AS4 + BGP4MP_ET and BMP's Route Monitoring message. As Claudio points out, syntax is easy, MRT could presumably be updated to carry the extra bits BMP has that MRT doesn't. Syntactic similarity notwithstanding, I have misgivings about attempting a merger. Although MRT and BMP cover similar problem spaces and the syntaxes could be brought into alignment, the semantics are different. I think this is not an accident and is caused by different design constraints. I won't presume to say what the assumptions were for MRT, but the high-level goals for BMP are spelled out in the abstract: "The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting." In particular, the "minimally service-affecting" (for a live, busy production router) goal turns out to have had extensive consequences. Here are some of the substantive differences between MRT and BMP: - MRT table dump uses a special format. BMP table dump is just a case of sending encapsulated Update messages, followed by an EoR. - MRT uses BGP4MP_MESSAGE messages to convey verbatim copies of update messages (Larry tells me that "the BGP messages are just copied in network byte order into the BGP Message field"). BMP Route Monitoring messages are generated afresh by the monitored router based on its RIB contents (the spec points out that "It's important to note that RM messages are not real time replicated messages received from a peer"). The above reflects my understanding of MRT from reading the spec and (in some cases) checking with Larry. The spec is a little light on defining semantics so in some cases I'm not 100% positive I have the right reading. Based on these differences, I wouldn't guess that an MRT listener could consume the output of a BMP speaker, even if the BMP speaker were updated to use MRT message formats. Similarly, it wouldn't be easy to convert a BMP speaker to provide MRT output (in fact, if BGP4MP_MESSAGE_* are really supposed to encap update messages as received, that's an explicit non-goal of BMP for scalability reasons). In sum, I question whether there is anything much to be gained from a merger. There's certainly something to be lost, in terms of delaying progress on BMP implementations. I'm thinking of adding a "comparison with MRT" appendix to the next version of the BMP draft since this question has come up a few times now. Thanks to Larry for answering my questions about MRT. --John _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
