Tim, On Wed, Jul 12, 2017 at 12:57:31AM +0000, Tim Evens (tievens) wrote: > [TE] IMO, limitations around transmission of X number of peers with *-rib-* > monitoring should be BMP > sender implementation specific. I do not believe anyone in their right mind > would configure a platform/sender > for *-rib-* on all peers, but you never know. This is why limits should > exist, a line in the sand, > for the platform. Limits that apply to one platform are not necessarily > required to be applied to another. > We want to enable the ability to monitor the five collection points of BGP > (Adj-RIB-In/pre, Adj-RIB-In/post, > Adj-RIB-Out/pre, Adj-RIB-Out/post, and Loc-RIB) but this doesn't mean the > platform can't restrict combinations.
As I already noted, I'm perfectly fine with the existing rib-out encoding. I simply believe that the per-group encoding offers flexibility to remove noise from BMP feeds for some of the same use cases. In particular, it avoids de-duping needs for operators in many scenarios. I find this less a matter of limits and more a matter of simple BGP procedure. A single update learned on one feed will usually result in multiple advertisements. Even with peer-group grouping, the fan out is often significantly higher. Given this, a mechanism to reduce information, where appropriate, seems reasonable. -- Jeff _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
