On Wed, Jul 12, 2017 at 12:57:31AM +0000, Tim Evens (tievens) wrote: > On 7/11/17, 5:20 PM, "GROW on behalf of Jeffrey Haas" <grow-boun...@ietf.org > on behalf of jh...@pfrc.org> wrote: > > In such cases - use the per peer rib-out. I do believe it has good > > use cases. However, discussions with our customers have suggested > > that in most cases it's excessively chatty and threatens to swamp > > the rib-in portion of the control channel they're actually > > interested in. For them, a general indication of rib-out content is > > sufficient, even when there's some minor variations with > > specifications they may be comfortable with. > > > [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.
I wouldn't be so quick to dismiss that from happening, nor frown upon it. It actually might be one of the first things I'd do when debugging an issue. And since quite some debugging is 'after the fact', it makes sense to permanently monitor at least Adj-RIB-In and Adj-RIB-Out for each peer. > BGP is big data, like IPFIX in that sense, and therefore should get > some engineering love, not willy-nilly turn it on everywhere and hope > for the best. I agree with you that BGP might be 'a lot of data' but storage space is cheap, so if the edge routers can send it I'll store it and keep it. I'm tired of flying blind. Also, I am not sure how I can select up front what BGP data I will keep, aggregate or throw away. To do proper triage on BGP hijacks we'll need per-prefix per-update granularity. Kind regards, Job _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
