Subject: [GROW] Discussion about: draft-cheng-grow-bgp-xml-00.txt from today's WG meeting

From: Christopher Morrow <[email-masked]>
Date: Thu, 26 Mar 2009 13:04:16 -0400

It would be very good to capture the discussion from today's WG
meeting about this document here, on-list. Would Rudiger and Dan be
willing to bring their discussion here in the next few days?

A quick summary was that processing time and storage expenses are
tradeoffs that XML formatting may bring as opposed to the current
binary formatting in MRT of the data.

Additionally there was some discussion on 'what is important to
capture' in the XML format. I believe Dan had also mentioned (perhaps
not in the WG meeting) that there would be a common/available toolset
to convert from MRT -> XML and XML -> MRT, so in the case where you
have legacy data stores you could plan to process via a common
pipeline regardless of the data format you choose going forward.

-Chris

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 26 Mar 2009 10:08:58 -0700

> binary formatting in MRT of the data.

I think one point that was made that XML is self-documenting while  
binary requires out-of-band documentation. If we're making a standard  
that's not really relevant as the standard will provide the  
documentation of the format...

One advantage of binary would be that you can easily read it directly  
from disk in a fairly random order without first having to decompress.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 26 Mar 2009 10:10:18 -0700

Hi Chris,

Also if someone could recapture the comments related to this work's 
interworking with bmp or it's relation to bmp it would be great.

I missed it via the audio and jabber seems quite sparse :).

Cheers,
R.

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
> 
>

---

From: David Meyer <[email-masked]>
Date: Thu, 26 Mar 2009 10:19:43 -0700

> documentation of the format...

	I'm having a tough time saying what I mean this week, but
	being in the business of collecting routing data, I can
	tell you that people want to know all kinds of
	information about what the network is doing which is not
	directly captured in the update stream or the format of
	the data. Dan described a few annontations that provide
	this type information.

	Dave

---

From: David Meyer <[email-masked]>
Date: Thu, 26 Mar 2009 10:21:56 -0700

> pipeline regardless of the data format you choose going forward.

	heas has already written MRT -> 'sh ip bgp' (that's how
	we're generating 'sh ip bgp' format data these days). So
	if we have XML->MRT, then we can generate all formats in
	use today from the XML. That would be a great step forward.

	Dave

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 26 Mar 2009 10:34:37 -0700

> I missed it via the audio and jabber seems quite sparse :).

Hi Robert,

BMP is about what data to suck out from a BGP peer
this work is about what's the best format to put that data in

Lixia

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 26 Mar 2009 10:46:56 -0700

Hi Lixia,

> this work is about what's the best format to put that data in

BMP defines what to send and how to send it ... it defines a new header 
to be used as a wrapper for the "raw" data.

As such it arrives on the management station.

What would such station do with it is outside of scope of bmp draft, but 
as currently defined/implemented there is no additional encoding of it 
between the router and mgmt station what so ever :).

Hence my question to clarify overlap between this work and bmp.

Cheers,
R.

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 26 Mar 2009 10:52:38 -0700

On Mar 26, 2009, at 10:46 AM, Robert Raszuk wrote:

> BMP defines what to send and how to send it ... it defines a new  
> header to be used as a wrapper for the "raw" data.
>
> What would such station do with it is outside of scope of bmp draft,  
> but as currently defined/implemented there is no additional encoding  
> of it between the router and mgmt station what so ever :).
>

agree.
what I said is a gross high level statement.
The above details definitely need to be clarified, if/when the WG  
agrees to take this work on.

We also meant to talk with BMP authors to sync up how best to handle  
this all (but as always, time is never enough to get all the things  
you wanted to get done to get done :-(

Lixia

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 26 Mar 2009 15:32:45 -0400

On Mar 26, 2009, at 1:52 PM, Lixia Zhang wrote:
> this all

My first inclination is to say that the management station is free to  
take the BMP stream and format it however it likes for storage.  If  
XML is liked, that's fine.

> (but as always, time is never enough to get all the things you  
> wanted to get done to get done :-(

Too true.

--John

---

From: "Payne@Eng" <[email-masked]>
Date: Thu, 26 Mar 2009 15:08:50 -0700

On Thu, Mar 26, 2009 at 10:46 AM, Robert Raszuk <[email-masked]> wrote:

> BMP defines what to send and how to send it ... it defines a new header to
> be used as a wrapper for the "raw" data.
> What would such station do with it is outside of scope of bmp draft, but as
> currently defined/implemented there is no additional encoding of it between
> the router and mgmt station what so ever :).
>

True, BMP encapsulates bgp 'raw' data with a simple header.
In such header, there is timestamp, peering information which is not in bgp
segments but is useful and necessary for the management station.

> Hence my question to clarify overlap between this work and bmp.
As you said, BMP defines what to send (Adj-RIB-in, Loc-RIB, Updates) and how
to send it(wrapped in a header over TCP).
In this draft, we focus on HOW to faithfually represent BGP segments in XML,
while also providing flexibility for annotation or taging.

We think It would be better to have a standard xml schema as early as
possible before multiple parties develop their own imcompatible xml formats.
This schema is not finallized and open to change based on working group
comments.

As for BMP, what maybe overlapped with bmp here is not this draft, but the
BGPMon project which we use to generates xml bgp messages. The major
difference is that a BMP process "resides" in a bgp router, so it is capable
to dump the whole adj-rib-in, while our BGPMon "peers" with routers, so it
only gets the best-path.

Payne

---

From: "Payne@Eng" <[email-masked]>
Date: Thu, 26 Mar 2009 15:03:35 -0700

Payne