> On Aug 4, 2015, at 6:27 PM, Ebben Aries <e...@fb.com> wrote:
> 
> 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

Good point. Please take a look at -14.

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

Thanks!

> 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.

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.

> 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

Thanks!

--John

> 
> 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
>> GROW@ietf.org
>> 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
>> 
> 
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Reply via email to