I said run-length-encoding. That's data compression, not state compression. The peers in a peer-group do not always get exactly the same updates.
Thanks, Jakob. > -----Original Message----- > From: Tim Evens (tievens) > Sent: Tuesday, July 11, 2017 6:34 PM > To: Jakob Heitz (jheitz) <[email protected]>; Jeffrey Haas <[email protected]> > Cc: [email protected] > Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: > draft-ietf-grow-bmp-adj-rib-out-00.txt) > > > > On 7/11/17, 6:03 PM, "Jakob Heitz (jheitz)" <[email protected]> wrote: > > 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. > > [TE] This is reasonable and per RFC78564 Route-monitoring is state > compressed. Adj-RIB-Out follows that > and supports both route-mirroring and route-monitoring. The > interval/throttle used for the state-compression > should be platform specific, but it should be documented so that we know the > granularity to expect. > State-compression should help reduce the number of updates but monitoring 100 > peers that belong to the > same update/peer group will likely be wasteful as there will be a lot of > duplication. In this case, > I go back to needing some engineering love. > > IMO, it does not make sense to monitor all of those peers if they in fact are > conveying the identical advertisements. > In either case, we need that peer group name in the PEER UP so that we can > correlate the peers to groups for proper > de-duplication. Unless we are monitoring for software bugs, the engineering > team/operators know which peers should > be monitored in order to get a proper group representation based on > egress/export policies. Although, this does put > a bit of a burden on engineering deployment. > > To address the engineering deployment use-case of monitoring only the > peer-group (export policy), it would be nice > to ease the monitoring configuration with the ability on the router to > dynamic select the peer to be monitored. For > instance, under the peer-group configuration for BMP monitoring, enable > "adj-rib-out best 2". The router then would > select the best 2 peers that represent the peer-group advertisements. This > can change over time as peers are added, > removed, or experience stability issues. In terms of BMP, normal > PEER_UP/PEER_DOWN with INFO TLV's would be used so > that the receiving system can easily correlate and de-dup as needed by > peer-group. If the doing peer-group > monitoring, the peer itself wouldn't matter as much. > > Peer group (including template) monitoring is not limited to Adj-RIB-Out. > The same use-case for monitoring the > peer-group for export policy can be said for Adj-RIB-In as well. The same > engineering/deployment configuration of > which peer is to be monitored for the peer-group name can be used for > Adj-RIB-In as well. Easing this configuration > for groups is beneficial. > > BTW… we absolutely need the OPEN message to convey the capabilities. This is > required to correctly parse the NRLI's > and attributes. > > > > > Thanks, > Jakob. > > > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
