Subject: [GROW] I-D Action:draft-ietf-grow-bmp-04.txt

From: [email-masked]
Date: Mon, 14 Jun 2010 07:45:24 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations Working Group of the IETF.

	Title           : BGP Monitoring Protocol
	Author(s)       : J. Scudder, et al.
	Filename        : draft-ietf-grow-bmp-04.txt
	Pages           : 16
	Date            : 2010-06-14

This document proposes a simple protocol, BMP, which can be used to
monitor BGP sessions.  BMP is intended to provide a more convenient
interface for obtaining route views for research purpose than the
screen-scraping approach in common use today.  The design goals are
to keep BMP simple, useful, easily implemented, and minimally
service-affecting.  BMP is not suitable for use as a routing
protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-grow-bmp-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: John Scudder <[email-masked]>
Date: Mon, 14 Jun 2010 07:57:51 -0700

FYI the changes in this version are summarized as

o  Require End-of-RIB marker after initial dump.	
o  Added Initiation message with string content.	
o  Changed assignment policy for IANA registries.	
o  Editorial changes.

I think this is fairly well baked.  I believe we've incorporated all feedback to date, so if you had a comment outstanding, please double-check it.

--John

On Jun 14, 2010, at 10:45 AM, <[email-masked]> <[email-masked]> wrote:

> <draft-ietf-grow-bmp-04.url><ATT00001..txt>

---

From: Claudio Jeker <[email-masked]>
Date: Mon, 21 Jun 2010 18:31:00 +0200

> http://www.ietf.org/internet-drafts/draft-ietf-grow-bmp-04.txt

I'm wondering why it is necessary to have a new way of dumping tables and
updates. IMO the MRT format is a very well known and accepted format.
There are existing parser libraries and many bgp implementations already
support this format.
Wouldn't it be better to make a joined effort to merge MRT and BMP?

-- 
:wq Claudio

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 21 Jun 2010 12:45:00 -0400

> Wouldn't it be better to make a joined effort to merge MRT and BMP?

bmp dumps the adj-rib-in ... with (I believe) some extra data that
MRT's not getting. I thought also that larry was looking to integrate
BMP feeds into the collector system that uses MRT today? (mrt being
the output format from a bgp listener like quagga)

-chris

---

From: Claudio Jeker <[email-masked]>
Date: Wed, 23 Jun 2010 22:31:20 +0200

> the output format from a bgp listener like quagga)

Which table is dumped is only an implementation detail. MRT could very
well dump the adj-rib-in or even the adj-rib-out. Some implementations do
allow that already.

It is very simple to extend the MRT format for the two new messages that
BMP has. Adding the Initiation Message and Stats Reports to MRT would
be simple.

I just see no point in trying to reinvent the wheel.
-- 
:wq Claudio

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 23 Jun 2010 17:03:55 -0400

> well dump the adj-rib-in or even the adj-rib-out. Some implementations do

near as I know... my juniper or cisco can't spew mrt ... bmp is/was
planned as a feature for routing devices to enable, on demand.

---

From: Larry Blunk <[email-masked]>
Date: Thu, 24 Jun 2010 11:13:35 -0400

> I just see no point in trying to reinvent the wheel.

     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.

  -Larry Blunk

---

From: John Scudder <[email-masked]>
Date: Fri, 25 Jun 2010 13:14:05 -0700

> 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