Subject: [Idr] BGP Monitoring Protocol

From: Russ White <[email-masked]>
Date: Mon, 15 Aug 2005 17:32:00 -0400

Y'all:

http://www.ietf.org/internet-drafts/draft-scudder-bmp-00.txt

BGP Monitoring Protocol, latest draft, posted.

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 15 Aug 2005 14:50:38 -0700

On Mon, 2005-08-15 at 17:32 -0400, Russ White wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Y'all:
> 

Russ,
grow WG seems to be working on:
http://ietf.org/internet-drafts/draft-ietf-grow-mrt-00.txt

Any chance the 2 efforts can be coordinated / merged ?
It seems that the objectives are similar...

  Pedro.

---

From: David Meyer <[email-masked]>
Date: Mon, 15 Aug 2005 15:02:56 -0700

Pedro,

> It seems that the objectives are similar...

	Possibly, though MRT talks about an output format, and
	BMP is talking about a way to collect the data (which
	might be output in MRT format, for example). However, the
	two are to large extent independent. For example, I may
	want to write a BGP listener that implements BMP and has
	flexible (e.g., pluggable) output formats, one of which
	may be MRT.

	Dave

---

From: Russ White <[email-masked]>
Date: Mon, 15 Aug 2005 18:07:02 -0400

> It seems that the objectives are similar...

Yep...

Glancing through the MRT spec, it looks a little different. It looks 
like MRT is encoding, rather than transport (or did I just miss that??). 
I would envision a working systems as something like this:

- -- Router implements BMP, which just reflects BGP packets to a listener.
- -- Listener implements some application that converts from BGP to MRT 
format for local storage.

My main concern with MRT is that it uses a different storage format for 
each different BGP message type, which means new ones need to be defined 
as new BGP message types are created (if they ever are). It looks like 
the same thing for all of the other protocols, as well. Would we really 
want to support each possible change on a router, along with the 
processing from the received BGP format into the MRT format before 
sending it to a monitoring station? Further, if we convert on the 
router, are we possibly losing some information critical to security 
systems trying to analyze traffic at a given BGP speaker?

Don't know the answers myself, just asking questions.

:-)

Russ

- --

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 15 Aug 2005 15:17:46 -0700

> format for local storage.

What is the difference between a socket and a file ? :-)
Would help to have a single format that can be output to a "storage"
location whether it is local or remote.

At least, at the moment, i don't see the advantage in having 2 formats.

> Don't know the answers myself, just asking questions.

All valid points. Seems like these are issues for the MRT format
regardless... i.e. if message conversion is a potential concern, it
would appear to be a concern for a collector that translates a BGP
session to a MRT file as well.

  Pedro.

---

From: David Meyer <[email-masked]>
Date: Mon, 15 Aug 2005 15:21:03 -0700

Russ,

	Both your and Pedro's points are well taken (and as such
	require more thought). And not that this should really
	gate what we eventually do, but there is quite a bit of
	code (and related analyzes) that rely on MRT format, so
	that is something else that requires some thought (to
	some extent and due to the zebra implmentation, MRT
	format became the de-facto standard). That being said,
	there is still a lot of code around that parses Cisco 
	'sh ip bgp' format archives, which we are still
	collecting... 

	Dave

---

From: Subhendu Ghosh <[email-masked]>
Date: Mon, 15 Aug 2005 18:38:23 -0400 (EDT)

> BGP Monitoring Protocol, latest draft, posted.

Needs a few line wraps for the message formats.

-- 
-rgds
sg

---

From: Larry Blunk <[email-masked]>
Date: Tue, 16 Aug 2005 17:00:14 -0400

>I would envision a working systems as something like this:

     Yes, it primarily deals with encoding rather than transport.  There 
were some rudimentary
efforts at dealing with transport (see control types in draft).  But it 
is not fully fleshed out and
has not been implemented to my knowledge.

>Don't know the answers myself, just asking questions.

   The deprecated BGP type has a different subtype for each BGP message 
type, but the
newer BGP4MP type (used by Zebra/Quagga and others) simply encodes the 
entire
BGP message.

 -Larry