Subject: Re: [GROW] WGLC: draft-ietf-grow-bmp - ENDS: 8/7/2015 (aug 7 2015)

From: Ebben Aries <[email-masked]>
Date: Tue, 4 Aug 2015 16:27:10 -0600

I've already expressed my support as this has long been needed to move
fwd - We @fb also have our own implementation of this that we've been
running for some time - few comments/minor-nits:

Section 1
- This is not by any means limited to researchers but has proven useful
already in a number of production deployments

Section 4.1
- Missing message type 0x06 for Route Mirroring Message

Section 4.10
- The variable length information field was added in -08.  I'm
understanding this use to be of a UDF included per peer (e.g.
description or some other string) in every Peer Up Notification message.
 My only comment here is since this is now introduced after the OPEN
messages, any leveraging of existing BGP libraries for
decoding/processing now needs to include pre-logic in order to determine
message len in order to pass back BMP processing of this info field post
BGP processing should it exist.  It would have been nice to keep this
field together w/ BMP specific values but would break any backwards
compat w/ earlier draft versions.

Section 10.1
- s/Monitor/Monitoring/  for Type 0
- Type 6: Route Mirroring
- May as well match up the nomenclature to that of Section 4.1

Thx

/ebben

On 07/18/2015 05:05 PM, Christopher Morrow wrote:
> Howdy Grow folk,
> I think at the meeting in 48hrs time Jon Scudder plans to ask (again)
> for WGLC for: draft-ietf-grow-bmp
> (https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/internet-drafts/draft-ietf-grow-bmp-09.txt&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A&m=V4WJF%2BC6g%2BF0DyGqUhE5247H124ekpCcy1f4x%2F9XEtU%3D%0A&s=58e343dc1a055a739a3937f70a23276d43d854adb525f2d88733d2a4e4e97068)
> 
> Let's all have  read through ,decide if we're happy and get this
> pushed along to the IESG for review/pulication. This is the abstract
> of the document:
> 
> "This document defines a protocol, BMP, that 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."
> 
> Thanks!
> -chris morrow
> (co-chair 1 or 2)
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/listinfo/grow&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A&m=V4WJF%2BC6g%2BF0DyGqUhE5247H124ekpCcy1f4x%2F9XEtU%3D%0A&s=78d83fb84b9e958c3d17ad5ca5020532f74adeec7ad27bf620931a086e84e3a4
>

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 7 Aug 2015 12:50:51 -0400

> On Aug 4, 2015, at 6:27 PM, Ebben Aries <[email-masked]> wrote:
> 

Good point. Please take a look at -14.

Thanks!

> compat w/ earlier draft versions.

I think you covered all the pros/cons. As you observe, the authors chose to resolve the tension in favor of backward compatibility. If there's consensus in the WG to change course and resolve the tension in favor of cleanliness at the expense of backward compatibility, we can do a respin.

Thanks!

--John

> https://www.ietf.org/mailman/listinfo/grow