How about some compression, like run-length-encoding instead of peer groups to reduce the firehose? A bunch of peers being sent nearly the same updates should compress very nicely and you wouldn't get all the confusion that comes with peer-groups.
Thanks, Jakob. > -----Original Message----- > From: Tim Evens (tievens) > Sent: Tuesday, July 11, 2017 5:58 PM > To: Jeffrey Haas <jh...@pfrc.org>; Jakob Heitz (jheitz) <jhe...@cisco.com> > Cc: grow@ietf.org > Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: > draft-ietf-grow-bmp-adj-rib-out-00.txt) > > Jeff, > > 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. 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. > > I'm also open to alternative encodings that permit better clustering of > the > messages to avoid redundant noise. > > [TE] YES, PEER UP INFO "peer/update group" TLV with engineered deployment > will do. I can't imagine any sizable > network > that has been configured without design/engineering. I do not believe or > suggest that is different with > BGP monitoring. 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. > > > --Tim _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
