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 protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/grow
