On Fri, Dec 17, 2010 at 3:01 PM, john heasley <h...@shrubbery.net> wrote: > Thu, Dec 16, 2010 at 09:07:11PM -0800, Stephen Stuart: >> I'm not sure what you're advocating to be configurable. Loc_RIB isn't >> interesting, you can get that by BGP-peering with the router if you're >> content to have the data obscured by best path selection. I'm not >> interested in turning BMP into a protocol for debugging malformed BGP >> updates, syslog already does that adequately. BMP is meant to do one >> job: allow a real computer to reproduce the Adj_RIB_In of a router, in >> a way that protects the router against conditions such as a bad >> receiver implementation or congestion loss between the speaker and the >> receiver. > > I'm suggesting that BMP can do both as it is defined now; and which is > exported could be user configurable on exporting device.
As noted, Loc_RIB can already be collected by peering with the device as a regular BGP peer. I would argue that introducing malformed updates runs the risk of introducing instability into a BMP receiver that may potentially cause it to lose state for a large Adj_RIB_In for no good cause, where the router will have (hopefully) just dumped the single BGP peer that sent the malformed update - and logging of the malformed update by the router using an existing mechanism like syslog is sufficient for what ought to be a rare event in the field. So, yes, BMP could do both, but there's no reason to add functionality to BMP to do jobs that are already done quite sufficiently by other mechanisms. Stephen _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
