Henk,
> On Sep 21, 2022, at 9:45 AM, Henk Smit <[email protected]> wrote: > > Hi Robert, > > > But this will hide BGP churn for a given NET to be detectable by BMP > > receiver. Is this a good thing ? > > The question is: how expensive is it to report everything bit-for-bit to the > BMP collector? > If you want to report everything, you have to store everything. > Which will require bufferspace. How much? You don't know in advance. Might be > a lot. Considerable in some cases. This is the core reason why BMP has distinct modes for route-monitoring (RFC 7854, §4.6) and route mirroring (RFC 7854, §4.7) The state compression that happens for route-monitoring is normally a feature. However, it means that BMP in route-monitoring mode with state compression is problematic for diagnosing certain types of BGP Update churn. In my experience, the bulk of customer needs are met with route-monitoring with state compression. One level of compromise that the protocol enables, but there's no RFC-specified mechanism for control, is tracing subsets of BGP state verbatim via route-mirroring on a dynamic basis. Instead of trying to shove the entire firehose of BGP from all of your feeds down the BMP drinking straw verbatim, use route-mirroring for targeted tracing. Even then, there's possibility of slow TCP speakers or other forms of backpressure causing you to eventually have too much to buffer. > The current way of doing things allows the BMP implementation on a router to > be pretty efficient. > When BGP receives routes, you store them in the BRIB. You don't store > anything special for BMP (expect maybe timestamps, or other meta-data). > When BMP on a router is going to send BMP updates, it just walks the BRIB, > and sees which NLRI/routes have not been sent to the collector yet. > BGP needs only 1 bit of information for that (to be precise: 1 bit per BMP > session per NLRI/route). Roughly, yes. Maybe a bit more state if you want to do bgp-style state suppression. (You have to track what you previously sent.) The rib-out feed is considerably uglier. -- Jeff _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
