Subject: Re: [GROW] New Version Notification for draft-petrie-grow-mrt-bmp-00.txt

From: Colin Petrie <[email-masked]>
Date: Fri, 1 Nov 2019 16:19:59 +0000

Hello Grow,

I posted draft-petrie-grow-mrt-bmp-00,
any and all comments are welcome.

This was a result of a discussion I had with some people about using MRT 
as a storage format for BMP messages.

Thanks,
Colin

On 01/11/2019 16:45, [email-masked] wrote:
> 
> A new version of I-D, draft-petrie-grow-mrt-bmp-00.txt
> has been successfully submitted by Colin Petrie and posted to the
> IETF repository.
> 
> Name:		draft-petrie-grow-mrt-bmp
> Revision:	00
> Title:		Storing BMP messages in MRT Format
> Document date:	2019-11-01
> Group:		Individual Submission
> Pages:		4
> URL:            https://www.ietf.org/internet-drafts/draft-petrie-grow-mrt-bmp-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-petrie-grow-mrt-bmp/
> Htmlized:       https://tools.ietf.org/html/draft-petrie-grow-mrt-bmp-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-petrie-grow-mrt-bmp
> 
> 
> Abstract:
>     This document extends the Multi-threaded Routing Toolkit (MRT) export
>     format to support the storage of BMP messages.
> 
>                                                                                    
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 1 Nov 2019 14:04:57 -0400

Colin,

> as a storage format for BMP messages.

While we're starting to get a bit recursive (BGP->BMP->MRT... what next?  ;-), 
this seems like a good thing to have.

The one addition I'd suggest for the document is that information about
peer-up/down messages is needed to usefully decode some information or
context about the other BMP messages.  You'll want a bit of operational
procedure in your text about "please save this bit of state in each file".

-- Jeff

---

From: Paolo Lucente <[email-masked]>
Date: Fri, 1 Nov 2019 18:22:08 +0000

Hi Jeff,

On 1 Nov 2019, at 19:04, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:

The one addition I'd suggest for the document is that information about
peer-up/down messages is needed to usefully decode some information or
context about the other BMP messages.  You'll want a bit of operational
procedure in your text about "please save this bit of state in each file”.

Or we can “save this bit of state” in the BMP message itself :-) I indeed refer to make this MRT draft depend on BMP v4 ( https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-tlv/ ) since, for example, we define there a handful TLVs for Stateless Parsing (it was more done to PoC the mechanism but indeed they would result entirely useful here). Should this be an approach we'd like to consider, of course it opens the door to further considerations, one for all: shall these TLVs be made mandatory?

Paolo

---

From: Colin Petrie <[email-masked]>
Date: Fri, 1 Nov 2019 19:43:58 +0000

> procedure in your text about "please save this bit of state in each file".

Indeed I was thinking about that as I wrote it. Maybe adding MRT 
subtypes like the BGP4MP type uses, to indicate state changes. The one I 
specifically thought of was the establishment and teardown of the BMP 
TCP connection. As I understand BMP, the termination message is 
optional, and of course the TCP connection could go down for other 
reasons. So preserving the fact that the session went down, would be 
useful there.

Thanks,
Colin

---

From: Colin Petrie <[email-masked]>
Date: Fri, 1 Nov 2019 19:57:06 +0000

On 01/11/2019 19:22, Paolo Lucente wrote:
> Or we can “save this bit of state” in the BMP message itself :-) I 
> indeed refer to make this MRT draft depend on BMP v4 ( 
> https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-tlv/ ) since, for 
> example, we define there a handful TLVs for Stateless Parsing (it was 
> more done to PoC the mechanism but indeed they would result entirely 
> useful here). Should this be an approach we'd like to consider, of 
> course it opens the door to further considerations, one for all: shall 
> these TLVs be made mandatory?

Yes either the BGP update encoding information need to be in the TLVs 
(like in BMP v4) or some more metadata in MRT to store this.
If the TLVs are not mandatory then this would have to be captured via an 
MRT method.

Thanks,
Colin

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 5 Nov 2019 14:42:10 -0500

> If the TLVs are not mandatory then this would have to be captured via an 

Minor issue with TLVs: They're decoration on an entire BMP PDU.

An impact of such TLVs on individual prefixes means that you end up
impacting route packing in the BGP state in the PDU.  More messages, more
work to encode/decode.

Note that I'm not saying there's anything WRONG with this.  However, people
are going to find that the cost of decoration is perhaps higher in terms of
performance than they may have expected.

-- Jeff